From rem-conf-request@es.net Sat Mar 01 04:33:06 1997 Received: from getafix.fcpl.co.in by osi-west.es.net with ESnet SMTP (PP); Sat, 1 Mar 1997 01:32:19 -0800 Received: from Forest_Gump.fcpl.co.in ([196.1.104.85]) by getafix.fcpl.co.in (post.office MTA v2.0 0613 ID# 291-17719) with ESMTP id AAA148 for ; Sat, 1 Mar 1997 03:06:41 -0600 From: Amitabh To: rem-conf Subject: Doubts regarding Multicasting Date: Sat, 1 Mar 1997 15:04:00 +0530 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <19970301090641102.AAA148@Forest_Gump.fcpl.co.in> Hi, I am Amitabh Mathrawala and am working on an experimental winsock (1.1 for now) compliant tcp/ip stack. Sorry to bother you with these doubts. Since I could'nt get any relevant information in this regard on the net, I am writing to you. I dont wish to take your time so in case I have missed out any obvious documentation, please let me know or any pointers to where I can get the relevant information. If you are aware of any news groups on this subject, it would be very helpful. I was in look out of any documentation that is authoritative on the subject (something like RFCs) because people have been suggesting me some common sense based solutions. Let me start with my doubts. Doubts regarding multi-casting --------------------------------- 1. Assume a single homed host. A datagram kind of socket S is opened. It joins a multicast group on the only inteface. Now is it necessary for the socket to specify INADDR_ANY (and port P) as the binding addresses while binding in order to receive multicast datagrams with target port P ? Or the socket can still receive multicast datagrams even if it is bound to the specific interface address (which is the only one available) and port P ? 2. Assume a multihomed host. A socket S joins a multicast group on interface I1. What address should it specify while binding in order to receive the multicast datagrams (of the joined group) coming on that interface and not any other interfaces? 3. Another similar situation. Lets say a machine has two interfaces I1 and I2. Open two sockets S1 and S2 on the machine. Let them join the same multicast group, say M, on the interfaces I1 and I2 respectively. (Note that such a thing is allowed). Let them be bound to addresses and . Now should the multicast datagrams of group M coming on interface I1 be forwarded/delivered to socket S2 ? Binding of datagram sockets --------------------------------------- 1. In a multihomed host, a datagram socket has been bound to INADDR_ANY address. What IP datagrams are delivered to such socket ? Meaning datagrams targeted to any of the interfaces or some specific addr . This is a redundant question if a datagram does get bound immediately after the bind call. With Regards. ~~~~~~~~~~~~~~ Amitabh Mathrawala Frontier Computers Pvt Ltd Pune, India Ph : (91)(212) 328640/321536 email : amitabh@fcpl.co.in ~~~~~~~~~~~~~~ If u have chosen to be a streetsweeper then sweep the streets as beethoven composed music or as michaelangelo painted . Sweep the streets so well that all the hosts of heaven and earth will stop by to say " Here lived a great street sweeper that did his job well". From rem-conf-request@es.net Sun Mar 02 18:28:20 1997 Received: from mailhost.nttlabs.com (actually ns.nttlabs.com) by osi-west.es.net with ESnet SMTP (PP); Sun, 2 Mar 1997 15:27:45 -0800 Received: from coltrane.nttlabs.com by mailhost.nttlabs.com (8.8.4+2.7Wbeta4/3.5Wpl2(97/01/23)) id PAA13232; Sun, 2 Mar 1997 15:27:40 -0800 (PST) Message-Id: <199703022327.PAA13232@mailhost.nttlabs.com> To: "Henning Schulzrinne (BL)" Cc: rem-conf@es.net, confctrl@isi.edu Subject: Re: New version of RTSP draft Reply-to: sumisu@nttlabs.com (Jeffrey D. Smith) In-reply-to: Your message of "Fri, 21 Feb 1997 17:58:47 EST" References: <330E28A7.1FC6@cs.columbia.edu> Date: Sun, 02 Mar 1997 15:27:39 -0800 From: Jeff Smith A few meta-level comments and questions before I dive in deeper... Regarding recording facilities: - who decides the name to be used for the stored stream in a record request? as written it appears that it is determined by the requesting party. Similar to HTTP PUT and POST it would seem necessary to have the ability for the server or the client to specify the abs_path or the URL. - SETUP seams to be for "setup stream" so I'm not sure this would be the proper place, but it is the request required before RECORD PAUSE: - can PAUSE indicate an SMPTE or Absolute Time stamp? Along the same lines: - a PLAY range will result in which? the server going to PAUSE at end of range or CLOSE at the end of range? js -- Jeffrey D. Smith Nippon Telegraph and Telephone Corporation Multimedia Communications Laboratories 250 Cambridge Ave., Suite 205 TEL +1 415 833 3605 Palo Alto, CA 94306 FAX +1 415 326 1878 ISDN +1 415 843 0667 new-pgp-fingerprint: 2F 95 88 54 C1 FB 75 25 BB 71 FC 8A 85 49 18 C2 old-pgp-fingerprint: C1 EE A9 BD B1 E9 2E 9A 03 CF 6B E1 CF C4 D0 0D e-mail: sumisu@nttlabs.com From rem-conf-request@es.net Sun Mar 02 22:27:36 1997 Received: from access.mbnet.mb.ca by osi-west.es.net with ESnet SMTP (PP); Sun, 2 Mar 1997 19:27:03 -0800 Received: from cliff (as3b-p05.mts.net [205.200.18.131]) by access.mbnet.mb.ca (8.8.5/8.8.5) with ESMTP id VAA25001 for ; Sun, 2 Mar 1997 21:26:58 -0600 (CST) Message-Id: <199703030326.VAA25001@access.mbnet.mb.ca> From: Cliff Strass To: rem-conf Subject: unsubscribe Date: Sun, 2 Mar 1997 18:08:18 -0600 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit unsubscribe From rem-conf-request@es.net Mon Mar 03 09:20:55 1997 Received: from snad.ncsl.nist.gov by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Mar 1997 06:20:20 -0800 Received: (from wchang@localhost) by snad.ncsl.nist.gov (8.7.5/8.7.3) id JAA03191; Mon, 3 Mar 1997 09:20:21 -0500 (EST) Date: Mon, 3 Mar 1997 09:20:21 -0500 (EST) Message-Id: <199703031420.JAA03191@snad.ncsl.nist.gov> To: rem-conf@es.net Subject: MBone camera for Windows 95/NT From: wchang@nist.gov (Wo Chang, x3439) I'm looking for a low cost, auto-focus, office use, monitor-/desk-top mounting with wide-angle video camera and a frame grabber (some might use parallel port instead, such as QuickCam) for running MBone vic video under Windows 95/NT. Any good suggestions or comments from your hands-on experiences? Thanks in advanced for any pointers. --Wo Chang From rem-conf-request@es.net Mon Mar 03 11:15:50 1997 Received: from dxmint.cern.ch by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Mar 1997 08:15:10 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id RAA31862; Mon, 3 Mar 1997 17:13:57 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA19412; Mon, 3 Mar 1997 17:13:56 +0100 Message-Id: <9703031613.AA19412@dxcoms.cern.ch> Subject: MBone broadcast of the CERN ATLAS meeting To: rem-conf@es.net, hepnet-l@slacvm.slac.stanford.edu, hrc@frcpn11.in2p3.fr, htasc@listbox.cern.ch, net-teleconferencing@listbox.cern.ch Date: Mon, 3 Mar 1997 17:13:56 +0100 (MET) From: Martin Fluckiger - CERN/CN/CS Cc: fle@dxcoms.cern.ch (Martin Fluckiger) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit CERN is pleased to announce the MBONE broadcast of the ATLAS Physics working group meeting and Plenary meetings -------------------------------------------------------- on Thursday/Friday 6/7 March 1997 from the CERN Auditorium Provisional Agenda: ------------------- >>> Times are UTC+1 <<< Thursday 6 March 1997 --------------------- 09h00 to 13h00 Physics working group 14h00 to 18h00 Plenary meeting I Friday 7 March 1997 ------------------- 09h00 to 13h00 Plenary meeting II The broadcast is announced via sdr as "CERN ATLAS". vat and vic applications will be used with a ttl of 127. In case of questions or problems please contact . This message is sent to distribution lists, sorry if you receive multiple copies of it. Best regards, -------------------------------------------------------------------- Martin Fluckiger & Christian Isnard CERN - CN/CS/EN multicast@noc.cern.ch European Laboratory for Particle Physics Computers and Networks division CH-1211 Geneva 23 - Switzerland From rem-conf-request@es.net Mon Mar 03 12:24:34 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Mar 1997 09:23:57 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id JAA04384 for ; Mon, 3 Mar 1997 09:24:10 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma004361; Mon Mar 3 09:23:26 1997 Received: by hille.msri.org (8.7/MSRI) id JAA05816; Mon, 3 Mar 1997 09:23:01 -0800 (PST) Date: Mon, 3 Mar 1997 09:23:01 -0800 (PST) Message-Id: <199703031723.JAA05816@hille.msri.org> To: rem-conf@es.net From: m1 Reply-to: m1@msri.org Subject: Cliff Taubes "Four Dimensional Topology I" MBone Broadcast Announcement ---------------------------- Title: Cliff Taubes "Four Dimensional Topology I" Date: Mar 04, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/events/taubes/ Description: An introduction to 4-dimensional topology and the Seiberg-Witten equations. Part I. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Mon Mar 03 12:26:11 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Mar 1997 09:24:57 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id JAA04429 for ; Mon, 3 Mar 1997 09:25:11 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma004413; Mon Mar 3 09:24:54 1997 Received: by hille.msri.org (8.7/MSRI) id JAA05846; Mon, 3 Mar 1997 09:24:31 -0800 (PST) Date: Mon, 3 Mar 1997 09:24:31 -0800 (PST) Message-Id: <199703031724.JAA05846@hille.msri.org> To: rem-conf@es.net From: m1 Reply-to: m1@msri.org Subject: Cliff Taubes "Four Dimensional Topology II" MBone Broadcast Announcement ---------------------------- Title: Cliff Taubes "Four Dimensional Topology II" Date: Mar 05, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/events/taubes/ Description: An introduction to 4-dimensional topology and the Seiberg-Witten equations. Part II. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Mon Mar 03 12:27:02 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Mar 1997 09:26:01 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id JAA04465 for ; Mon, 3 Mar 1997 09:26:13 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma004447; Mon Mar 3 09:25:17 1997 Received: by hille.msri.org (8.7/MSRI) id JAA05876; Mon, 3 Mar 1997 09:24:53 -0800 (PST) Date: Mon, 3 Mar 1997 09:24:53 -0800 (PST) Message-Id: <199703031724.JAA05876@hille.msri.org> To: rem-conf@es.net From: m1 Reply-to: m1@msri.org Subject: Cliff Taubes "Four Dimensional Topology III" MBone Broadcast Announcement ---------------------------- Title: Cliff Taubes "Four Dimensional Topology III" Date: Mar 06, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/events/taubes/ Description: An introduction to 4-dimensional topology and the Seiberg-Witten equations. Part III. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Mon Mar 03 12:28:39 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Mar 1997 09:27:04 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id JAA04535 for ; Mon, 3 Mar 1997 09:27:16 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma004505; Mon Mar 3 09:27:08 1997 Received: by hille.msri.org (8.7/MSRI) id JAA05910; Mon, 3 Mar 1997 09:26:45 -0800 (PST) Date: Mon, 3 Mar 1997 09:26:45 -0800 (PST) Message-Id: <199703031726.JAA05910@hille.msri.org> To: rem-conf@es.net From: joe Reply-to: joe@msri.org Subject: John Conway "Knotation" MBone Broadcast Announcement ---------------------------- Title: John Conway "Knotation" Date: Mar 10, 1997 Time: 16:00 PST8PDT 1 hours Contact: joe@msri.org URL: http://www.msri.org/lecturenotes/97/conway/ Description: How can we choose names for simple knots so that we can always rebuild a knot from its name, and yet so that it will usually be easy to find the name from any form of the knot? I shall describe a simple arithmetical notation that accomplishes this for a large class of knots. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Mon Mar 03 12:45:44 1997 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Mar 1997 09:43:36 -0800 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id JAA05825; Mon, 3 Mar 1997 09:43:31 -0800 (PST) Message-Id: <199703031743.JAA05825@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: wchang@nist.gov (Wo Chang, x3439) cc: rem-conf@es.net Subject: Re: MBone camera for Windows 95/NT In-reply-to: Your message of "Mon, 03 Mar 1997 09:20:21 EST." <199703031420.JAA03191@snad.ncsl.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 03 Mar 1997 09:43:31 -0800 From: Amancio Hasty Check out the WinCastTV it usually sells for $149: http://www.hauppauge.com/hcw/html/wc_data.htm This is a high speed PCI video capture board and it also has a tuner. Enjoy, Amancio >From The Desk Of Wo Chang, x3439 : > I'm looking for a low cost, auto-focus, office use, > monitor-/desk-top mounting with wide-angle video camera > and a frame grabber (some might use parallel port instead, > such as QuickCam) for running MBone vic video under > Windows 95/NT. Any good suggestions or comments from > your hands-on experiences? > > Thanks in advanced for any pointers. > > --Wo Chang From rem-conf-request@es.net Mon Mar 03 14:18:30 1997 Received: from nobozo.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Mar 1997 11:17:18 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id LAA22621 for ; Mon, 3 Mar 1997 11:17:17 -0800 Date: Mon, 3 Mar 1997 11:17:17 -0800 Message-Id: <199703031917.LAA22621@nobozo.CS.Berkeley.EDU> X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: Jerrlyn Iwata Subject: [Reminder] Berkeley Multimedia & Graphics Seminar Berkeley Multimedia and Graphics Seminar (Wednesday March 5, 1997 12:30-2:00 PDT 405 Soda Hall) "The Internet as a Populated Place" Pavel Curtis PlaceWare, Inc. MBONE BROADCAST BEGINS AT 12.40 PDT (GMT - 8 HOURS) From rem-conf-request@es.net Mon Mar 03 14:43:54 1997 Received: from kodiak.ucla.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Mar 1997 11:42:50 -0800 Received: from elm.cns.ucla.edu (elm.cns.ucla.edu [164.67.222.20]) by kodiak.ucla.edu (8.8.5/8.6.9) with SMTP id TAA23638 for ; Mon, 3 Mar 1997 19:42:46 GMT Date: Mon, 3 Mar 1997 19:42:46 GMT Message-Id: <199703031942.TAA23638@kodiak.ucla.edu> From: Scott Burris Content-Type: text/plain;charset=US-ASCII To: rem-conf@es.net Subject: University of California Teching and Learning Technologies Conference X-Mailer: Pronto97 E-Mail [ver 4.0 CodeFreeze] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: Normal This invitational conference will bring together faculty, library, computing and instructional development professionals, administrators and students from throughout the University for an intensive consideration of the possibilities and challenges we face in incorporating new information and communication technologies into the heart of the teaching mission. This event is scheduled for March 25 and March 26. Selected programs are planned for broadcast over the MBONE. See http://www.ucop.edu/ucophome/auc/ and the sdr announcements for details. We plan to use one video and one audio channel. Questions about the conference may be directed to Martha Winnacker . Questions or concerns about the broadcast may be directed to mbone- admin@ctns.ucla.edu. ---------------- Scott Burris UCLA Campus Telecommunications and Network Services scott@ctns.ucla.edu From rem-conf-request@es.net Mon Mar 03 16:05:43 1997 Received: from venus.Sun.COM by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Mar 1997 13:04:02 -0800 Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA24290 for ; Mon, 3 Mar 1997 13:03:59 -0800 Received: from valathar.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA09495; Mon, 3 Mar 1997 13:03:57 -0800 Received: from valathar by valathar.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA05038; Mon, 3 Mar 1997 13:03:50 -0800 Date: Mon, 3 Mar 1997 13:03:50 -0800 (PST) From: "Michael F. Speer" Reply-To: "Michael F. Speer" Subject: Sunergy Broadcast To: rem-conf@es.net cc: Michael.Speer@Eng.Sun.COM Message-ID: Content-Type: text X-Sun-Text-Type: ascii SUNERGY 25 "NEXT GENERATION NETWORKING" Live from Mountain View, California March 6, 1997 Broadcast Time: 8:30 - 9:30 am (Pacific Time) 16:30-17:30 (GMT) SUNERGY 25 breaks the network bottleneck, exploring routes around perceived bandwidth limitations in networked environments. Strategies for extending the capacity of the existing copper resources and launching community based fiber initiatives are explored. Streaming video, object switching, and wireless technologies bring the data to your doorstep. Check the Sunergy website for guest bios, satellite coordinates and other details. >From outside of Sun: http://www.sun.com/sunergy/ Within Sun: http://sunwww.ebay/sunergy/ GUESTS: JOHN GAGE (host), Director of the Science Office, Sun Microsystems Computer Company GEOFFREY BAEHR (co-host), Chief Networking Officer, Sun Microsystems TOM LYON, Founder and CTO, Ipsilon Networks, Inc. CHARLES PERKINS, Head, Internet Engineering Task Force, Mobile IP Group LAWRENCE ROBERTS, President, ATM Systems AUDIENCE PROFILE: - Technologists wishing to keep up with the latest developments in networking - Developers for whom networked or distributed computing represents a competitive advantage - Business planners who need to consider local and global networking for running their enterprises - Anyone interested in keeping up with the business of distributed computing. TECHNICAL CONTENT RATING: 4 (On a scale of 1-5, 5 being most technical) STUDIO AUDIENCE: Those in the Mountain View, California area are welcome to join us in the studio for the live broadcast. If you are interested in doing so, please send a request to sunergy@sun.com for directions to the studio and to be included on the audience list. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This interactive television broadcast will be available live, via satellite in NORTH AMERICA, SOUTH AMERICA and EUROPE. Participate in the show by asking a question of the guests during the live broadcast: Telephone: 1-415-988-1171 Fax: 1-415-988-7003 Or via the "Chat Room" on the Sunergy website: http://www.sun.com/sunergy/front.html SATELLITE INFORMATION: http://www.sun.com/sunergy/satellite.html [within Sun, go to: http://sunwww.ebay/sunergy/satellite.html] VIDEO ORDERING INFORMATION: http://www.sun.com/sunergy/videoorder.html [within Sun, go to: http://sunwww.ebay/sunergy/videoorder.html] Questions? Or if you want any of the information available on the website emailed to you, contact: Sunergy Office 1-415-786-8205 sunergy@sun.com From rem-conf-request@es.net Mon Mar 03 20:41:01 1997 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Mar 1997 17:40:23 -0800 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id RAA10294 for ; Mon, 3 Mar 1997 17:40:25 -0800 (PST) Message-Id: <199703040140.RAA10294@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: rem-conf@es.net Subject: Video Capture for FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 03 Mar 1997 17:40:25 -0800 From: Amancio Hasty The latest Bt848 device driver supports the following cards: o WinCast/TV o STB PC TV o Intel Smart Video Recorder III A module is included to support vic. The latest driver also supports direct PCI to PCI data transfer so for instance one can display the capture frames directly on your display. This is a PCI bus master transfer that is the CPU is not used at all and all the data transfer goes thru the PCI bus. The overall effect is well very smooth video display. For more info just download the driver and see the README file. ftp://rah.star-gate.com/pub/bt848-0.3.tar.gz For on-going discussions about multimedia on FreeBSD post to multimedia@freebsd.org Enjoy, Amancio From rem-conf-request@es.net Mon Mar 03 20:47:40 1997 Received: from accuracy.total.net by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Mar 1997 17:46:56 -0800 Received: from [204.19.114.29] (ppp-0119.infobahnos.com [204.19.114.29]) by accuracy.total.net (8.8.5/8.8.5) with ESMTP id UAA06018 for ; Mon, 3 Mar 1997 20:46:52 -0500 (EST) Date: Mon, 3 Mar 1997 20:46:52 -0500 (EST) Message-Id: In-Reply-To: <199703031420.JAA03191@snad.ncsl.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: Sprinter Subject: who From rem-conf-request@es.net Tue Mar 04 04:48:14 1997 Received: from mailhub.axion.bt.co.uk by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Mar 1997 01:47:17 -0800 Received: from rambo.futures.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Tue, 4 Mar 1997 09:43:16 +0000 Received: from mussel.drake.bt.co.uk (actually mussel.futures.bt.co.uk) by rambo.futures.bt.co.uk with SMTP (PP); Tue, 4 Mar 1997 09:44:32 +0000 Received: by mussel.drake.bt.co.uk with Microsoft Exchange (IMC 4.0.837.3) id <01BC287F.DA623C80@mussel.drake.bt.co.uk>; Tue, 4 Mar 1997 09:38:44 -0000 Message-ID: From: Benoit Gaillard To: "'rem-conf@es.net'" Subject: unsubscribe Date: Tue, 4 Mar 1997 09:39:15 -0000 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Encoding: 17 TEXT unsubscribe ________________________________________________________ Benoit GAILLARD - B29 Rm138 Phone : 00-44-(0)1473-647609 ________________________________________________________ >---------- >From: Sprinter >Sent: Tuesday, March 4, 1997 3:46 am >To: rem-conf@es.net >Subject: who > > > > From rem-conf-request@es.net Tue Mar 04 05:13:44 1997 Received: from acacia.sucs.soton.ac.uk by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Mar 1997 02:13:03 -0800 Received: from willow.sucs.soton.ac.uk (willow.sucs.soton.ac.uk [152.78.128.20]) by acacia.sucs.soton.ac.uk (8.8.2/server) with ESMTP id KAA08372; Tue, 4 Mar 1997 10:12:13 GMT Received: from mercury.sucs.soton.ac.uk ([152.78.175.74]) by willow.sucs.soton.ac.uk (8.8.4/client-8.8) with SMTP id JAA07699; Tue, 4 Mar 1997 09:45:54 GMT Date: Tue, 4 Mar 1997 09:42:34 GMT From: David Holter Subject: Re: MBone camera for Windows 95/NT To: "Wo Chang, x3439" cc: rem-conf@es.net Message-ID: Priority: Normal MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Mon, 3 Mar 1997 09:20:21 -0500 (EST) Wo Chang, x3439 wrote: > From: Wo Chang, x3439 > Date: Mon, 3 Mar 1997 09:20:21 -0500 (EST) > Subject: MBone camera for Windows 95/NT > To: rem-conf@es.net > > I'm looking for a low cost, auto-focus, office use, > monitor-/desk-top mounting with wide-angle video camera > and a frame grabber (some might use parallel port instead, > such as QuickCam) for running MBone vic video under > Windows 95/NT. Any good suggestions or comments from > your hands-on experiences? > > Thanks in advanced for any pointers. > > --Wo Chang Ive been using a Stinger card and the Flexcam camera from MacLine 0181 401 1118 which works quite well with some applications but I havent been able to get vic to run on the PC yet is crashes after a few seconds each time. I think there are still a few things to sort out in the PC software. Regards David Holter Networking Group Computing Services University of Southampton UK +44 1703 593571 +44 1703 593939 D.A.Holter@soton.ac.uk From rem-conf-request@es.net Tue Mar 04 08:43:00 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Mar 1997 05:42:12 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id FAA20836 for ; Tue, 4 Mar 1997 05:42:26 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma020828; Tue Mar 4 05:41:27 1997 Received: by hille.msri.org (8.7/MSRI) id FAA06399; Tue, 4 Mar 1997 05:41:03 -0800 (PST) Date: Tue, 4 Mar 1997 05:41:03 -0800 (PST) Message-Id: <199703041341.FAA06399@hille.msri.org> To: rem-conf@es.net From: m1 Reply-to: m1@msri.org Subject: Xiao-Song Lin "Combinatorics and low dimensional topology" MBone Broadcast Announcement ---------------------------- Title: Xiao-Song Lin "Combinatorics and low dimensional topology" Date: Mar 11, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/lecturenotes/97/lin/ Description: Lin's lecture from the Combinatorial Problems Arising in Knots and 3-Manifolds workshop. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Mar 04 08:43:38 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Mar 1997 05:42:13 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id FAA20843 for ; Tue, 4 Mar 1997 05:42:27 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma020832; Tue Mar 4 05:42:15 1997 Received: by hille.msri.org (8.7/MSRI) id FAA06429; Tue, 4 Mar 1997 05:41:53 -0800 (PST) Date: Tue, 4 Mar 1997 05:41:53 -0800 (PST) Message-Id: <199703041341.FAA06429@hille.msri.org> To: rem-conf@es.net From: m1 Reply-to: m1@msri.org Subject: Serge Tabachnikov "Legendrian and transverse knots in tight contact structures" MBone Broadcast Announcement ---------------------------- Title: Serge Tabachnikov "Legendrian and transverse knots in tight contact structures" Date: Mar 12, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/lecturenotes/97/tabachnikov/ Description: Tabachnikov's lecture from the Combinatorial Problems Arising in Knots and 3-Manifolds workshop. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Mar 04 08:44:43 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Mar 1997 05:43:15 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id FAA20887 for ; Tue, 4 Mar 1997 05:43:28 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma020864; Tue Mar 4 05:42:33 1997 Received: by hille.msri.org (8.7/MSRI) id FAA06459; Tue, 4 Mar 1997 05:42:11 -0800 (PST) Date: Tue, 4 Mar 1997 05:42:11 -0800 (PST) Message-Id: <199703041342.FAA06459@hille.msri.org> To: rem-conf@es.net From: m1 Reply-to: m1@msri.org Subject: Dror Bar Natan "Wheels, Wheeling and the Kontsevich integral of the unknot" MBone Broadcast Announcement ---------------------------- Title: Dror Bar Natan "Wheels, Wheeling and the Kontsevich integral of the unknot" Date: Mar 13, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/lecturenotes/97/bar-natan/ Description: Bar Natan's lecture from the Combinatorial Problems Arising in Knots and 3-Manifolds workshop. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Mar 04 13:05:19 1997 Received: from soleil.uvsq.fr by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Mar 1997 10:04:09 -0800 Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id TAA21703 ; Tue, 4 Mar 1997 19:00:46 +0100 (MET) From: 2IN97@prism.uvsq.fr Received: from davoult.prism.uvsq.fr (davoult.prism.uvsq.fr [193.51.25.134]) by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with SMTP id RAA19259 for ; Tue, 4 Mar 1997 17:48:43 +0100 (MET) Message-ID: <331C5126.56FA@prism.uvsq.fr> Date: Tue, 04 Mar 1997 17:43:18 +0100 Organization: Prism X-Mailer: Mozilla 3.0Gold (Win95; I) MIME-Version: 1.0 To: congres@prism.uvsq.fr Subject: Call for papers 2IN97 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by soleil.uvsq.fr id TAA21703 ________________________________________________________________________ We apologize for multiple copies=20 ________________________________________________________________________ CALL FOR PAPERS 1997 International Conference Intelligent Networks and Intelligence in Networks =20 (2IN97) Paris - France=20 September 2-5, 1997 Organizer : IFIP TC WG 6.7 - Intelligent Networks Sponsorship requested : Alcatel, Ericsson, France Telecom, Nokia, Nordic teleoperators, Siemens, Telecom Finland, Lab. PRiSM Aim of the conference To identify and study current issues related to the development of intelligent capabilities in networks. These issues include the development and distribution of services in broadband and mobile networks. This conference belongs to a series of IFIP conference on Intelligent Network. The first one took place in Lappeeranta August 94, the second one in Copenhagen, August 95. The proceedings of both events have been published by Chapman&Hall. IFIP Working Group 6.7 on IN has concentrated with the research and development of Intelligent Networks architectures. First the activities have concentrated in service creation, service management, database issues, feature interaction, IN performance and advanced signaling for broadband services. Later on the research activities have turned towards the distribution of intelligence in networks and IN applications to multimedia and mobility. The market issues of new services have also been studied. From the system development point of view, topics from OMG and TINA-C have been considered. Main fields of interest to 2IN97: IN Markets and trends - Value added services market=20 - Development in telecom area - Multimedia IN - IN and the Internet Standardization/integration and legacies - Standardization aspects - TINA - IN and B-ISDN - IN and mobile networks - Intelligence in ATM networks Service types, service architecture and=20 - Service creation, distribution and management - IN service architecture - Service creation architecture applied in multimedia services (voice, data, mobile) - Multimedia services Tools - Intelligent control schemes - Multimedia call models - Multimedia call control protocols - Intelligent routing - Continuous media - Performance issues - Intelligent agents - Distributed artificial intelligence and multi-agent systems for networks - JAVA technology for IN services IN systems and platforms - IN architecture - Intelligence and Network Management - Real time data bases and caches for services Workshop organization Lab PRiSM (University of Versailles) Place of the conference : French Ministry of Telecommunication, Avenue de Segur, Paris, France Conference chair:=20 Olli Martikainen FIN=20 Guy Pujolle F Program committee chair : Dominique Ga=EFti F Program committee members James Aitken UK Almeida Maria J.B. BR Andy Bihain USA Gilles Bregant F Carla Capellmann, GER Christian Chabernaud F Peter Delgado UK Heinz Dibold GER Jacques Ferber F Frank Gallivan USA Philip Ginzboorg FIN Shri Goyal USA Serge Haddad F Heikki Hammainen FIN Villy Baek Iversen DK Bijan Jabbari USA Jorma Jormakka FIN Koos Koen RSA Ulf K=F6rner S Paul K=FChn GER Roberto Kung F Jacques Labetoulle F Xuejia Lai CH Martine Lapierre F Kari Lautanala FIN Aurel A. Lazar USA Olli Martikainen FIN=20 Valeri A. Naoumov RF Karl W. Neunast GER Jorgen Norgaard DK Herv=E9 Precioso F Guy Pujolle F Kimmo Raatikainen FIN Konstantin E. Samouylov RF Manfred Schneps-Schneppe RUS Lennart S=F6derberg S Haitao Tang CN Organization chair : Nadia Boukhatem F Thierry Hua F Important dates: March 21, 1997: Deadline for Paper Submission May 15, 1997: Notification of Acceptance July 1, 1997: Final Version Due September 2, 1997: Tutorial September 3-5, 1997: Conference Instructions: Submit five copies of a full paper by March 21, 1997. Papers should be no longer than 20 double spaced typewritten pages, including tables and figures. The proceedings will be published by Chapman&Hall All correspondence should be addressed: - by email (postcript version of the paper) - 2IN97@prism.uvsq.fr - or by mail to 2IN97 Conference Lab PRiSM - University of Versailles 45 av. des Etats-Unis 78035 Versailles Cedex - France ------------------------------------------------------------------------ 2IN'97 1st Name: .............................................................. Last Name:.............................................................. email:.................................................................. Title:.................................................................. Organization:........................................................... Postal address:......................................................... ........................................................................ City:..............................Postal code:......................... Country:................................................................ Telephone:.............................................................. Fax:.................................................................... O Topics I am interested in:............................................ O I wish to attend the ICCC'97 conference. O I wish to present a paper and will submit a paper by March 21, 1997.=20 Title of the paper : ........................................................................ ........................................................................ ........................................................................ ________________________________________________________________________ ________________________________________________________________________ From rem-conf-request@es.net Tue Mar 04 13:54:30 1997 Received: from postbox.dai.ed.ac.uk by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Mar 1997 10:53:48 -0800 Received: from sole (sole.dai.ed.ac.uk [192.41.107.4]) by postbox.dai.ed.ac.uk (8.6.13/8.6.12) with ESMTP id SAA06573; Tue, 4 Mar 1997 18:37:07 GMT From: michael@dai.ed.ac.uk Date: Tue, 4 Mar 1997 18:34:31 GMT Message-Id: <7578.199703041834@sole> To: BENKING@faw.uni-ulm.de, E.Slarke@unsw.edu.au, EricT@cov.ac.uk, Guy.VanBelle@rug.ac.be, IETF@cnri.reston.va.us, J.L.Leach@maths.bath.ac.uk, M.North@lcad.ac.uk, N.G.Cross@open.ac.uk, N.Oloughlin@lcad.ac.uk, Pcrofts@chelt.ac.uk, Peter.Thomas@csm.uwe.ac.uk, S.M.Loke@u.ac.shef.ac.uk, WGODWIN@chelt.ac.uk, alg@comm.toronto.edu, armin@mic.atr.co.jp, atm@bbn.com, bota@race.u-tokyo.ac.jp, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, cost237-transport@comp.lancs.ac.uk, ed1@mdx.ac.uk, enternet@bbn.com, fokus-user@fokus.gmd.de, giga@tele.pitt.edu, hipparch@sophia.inria.fr, hoffmann@osiris.iemar.tuwien.ac.at, isadsoc@fokus.gmd.de, jwworth@jupiter.informatik.umu.se, knishi@mic.atr.co.jp, multicomm@cc.bellcore.com, osimcast@bbn.com, performance@haven.epm.ornl.gov, rafaelp@cogs.susx.ac.uk, rem-conf@es.net, reres@laas.fr, sbell@bmth.ac.uk, schmid@dfki.uni-kl.de, sigmedia@bellcore.com, sugi@rd.nacsis.ac.jp, tccc@cs.umass.edu, urban@egd.igd.fhg.de, xtp-relay@cs.concordia.ca, yevin@sam.imash.ras.ru Subject: EuropIA europia`97 @EDINBURGH ------------------ DESIGN and the NET ------------------ http://www.caad.ed.ac.uk/europia/ Details and Provisional Programme --------------------------------- Sixth International Conference on the Application/Implications of Computer Networking in Architecture, Construction, Design, Civil Engineering and Urban Planning Sixime Confrence Internationale sur les applications/implications des nouvelles technologies de communication en Architecture, Construction, Design, Ingnierie et Planification urbaine 2-3 April 1997 Department of Architecture University of Edinburgh Edinburgh EH1 1JZ Scotland http://www.caad.ed.ac.uk/europia/ This conference brings together researchers in design, architecture, engineering, construction management, cognitive science, computer science, artificial intelligence, sociology, geography and education as well as industry partners, practitioners and other users of networked communications. The focus for this diverse group is design - how we design with and for networked communications - appropriating recent exciting developments in medium and broad band local area and wide area networks, new protocols for interaction and new communications tools such as Web browsers and network aware multimedia tools. DATES Conference 2-3 April 1997 REGISTRATION FEE Authors 175 pounds stirling Non-authors 250 pounds stirling Conference Dinner 27 pounds stirling VENUE UnivEd Training and Conference Centre 11 South College Street Edinburgh EH8 9AA SEND QUEURIES ABOUT REGISTRATION AND ACCOMMODATION TO Ronnie Galloway Conference Manager Ronnie.Galloway@ed.ac.uk UnivEd Technologies Limited 11 South College Street, Edinburgh, EH8 9AA Ph +44 131 650 9020 Fax +44 131 650 9019 EuropIA'97 Design and the Net 2-3 April 1997 +++++++++++++++++++++++++++++++++++++++++ Provisional Programme ===================== (4/3/97) Wednesday 9.15-9.30 Welcome Working with the web: Networked CAD applications 9.30-10.00 . Common libraries for networked engineering applications Tuttle et al 10.00-10.30 . The VRML model of the city of Bath Bourdakis and Day 10.30-11.00 break 11.00-11.30 . Shared information system for urban and architectural design Caneparo 11.30-12.00 . Communication in distributed statistical frameworks for historic building documentation: The abbey of Valmagne Warden & Vasquez 12.00-12.30 . CAD On-line Coyne & Lee 12.30-2.00 lunch Working with the web: Innovation and technology 2.00-2.30 . A method for organising and sharing architectural project information in the WWW Ofluoglu & Kalisperis 2.30-3.00 . Designing learning environments using java Pang & Edmonds 3.00-3.30 . A web -based design support environement for knowledge discovery and machine learning Branki, Bridges, Wallis & Aird 3.30-4.00 break 4.00-4.30 . Ways of aiding navigation in VRML worlds Caritos and Rutherford 4.30-5.00 . Multilevel representations of architectural designs Koutamanis 5.00-5.30 . A network aid for design project management Roussel & Zriek Thursday The web in practice: Education in cyberspace 9.30-10.00 . The tex-mex virtual design studio Vasquez & Trigo 10.00-10.30 . Networked based decision support for building design Burry & Smithers 10.30-11.00 . Digital design: students communicating experiential spatial qualities in a networked computing environment Burley, Megza & Bauer 11.00-11.30 break The web in practice: The emerging webculture 11.30-12.00 . HQ video conferencing and its application to the teaching of architecture Lindsay & Grant 12.00-12.30 . Sedimented practices of 'reading' design descriptions: from paper to screen Tweed 12.30-1.00 . The architect's role in the information age Rossis 1.00-2.00 lunch 2.00-2.30 . Collaborative design by discovery and the web Peng 2.30-3.00 . Method DTN: Design through the net Reze 3.00-3.30 . A cyberspace in time Szalapaj & Filho 3.30-4.30 Poster Session The web in practice: The emerging webculture (cont.) 4.30-5.00 . A virtual monoculture of visual communication Newton & Shi 5.00-5.30 . Design information and the superhighway: roadworks ahead? Ramscar & Lee 5.30-6.00 Plenary Session Poster Session . A web based experience of a collaborative argumentation system design Chen, Branki & Newman . Networked collaborative design implementation Burry, Coll & Serrano . Up the down staircase... Brady . Broadband videoconference workstation Brandt et al . DesignNet electronic journal Westphal & Burley . Cybernetic theory & architecture Hunt . Intranets as tools for strategy Thomas . Building an intranet model for CAAD Paranandi From rem-conf-request@es.net Tue Mar 04 20:19:26 1997 Received: from digitcom.com (actually div-n.digitcom.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Mar 1997 17:17:25 -0800 Received: from 206.83.179.68 ([206.83.179.68]) by digitcom.com (8.6.12/8.6.12) with SMTP id RAA08369 for ; Tue, 4 Mar 1997 17:28:06 -0800 Message-ID: <331CCA76.6579@digitcom.com> Date: Tue, 04 Mar 1997 17:20:54 -0800 From: Roger Templeton Reply-To: rogert@digitcom.com Organization: Digitcom Interactive Multimedia Corporation X-Mailer: Mozilla 2.0 (Macintosh; I; PPC) MIME-Version: 1.0 To: rem-conf Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe From rem-conf-request@es.net Tue Mar 04 20:58:50 1997 Received: from gatekeeper.sprintlabs.com (actually dmz.sprintlabs.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Mar 1997 17:58:07 -0800 Received: by gatekeeper.sprintlabs.com id AA19071 (5.67b/IDA-1.5 for ); Tue, 4 Mar 1997 18:03:30 -0800 Received: from unknown(199.2.53.28) by gatekeeper.sprintlabs.com via smap (V3.1) id xma019068; Tue, 4 Mar 97 18:03:25 -0800 X-Sender: aollikai@gatekeeper Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 4 Mar 1997 18:03:26 -0800 To: rem-conf@es.net From: ari@sprintlabs.com (Ari Ollikainen) Subject: How to UNSUBSCRIBE from rem-conf I'm posting the following information as a public service: To UNSUBSCRIBE from the rem-conf list send your UNSUBSCRIBE request (in both Subject: line and body of message) to: rem-conf-request@es.net The list maintainers do NOT read the messages sent to the whole list. Back when I ran/maintained this list, I used to post a periodic reminder for change requests and archive(s) location...I also studiously ignored drop requests sent to the whole list unless I had some time available to service them. Please do NOT send *me* any requests for changes...I've moved on... _/_/ _/_/_/_/ _/ Ari Ollikainen _/ _/ _/ _/ _/ Sprint Advanced Technology Laboratories _/_/_/_/ _/_/_/_/ _/ Switching and Interworking Development _/ _/ _/ _/ _/ 1 Adrian Court (M/S: CABURS0102) _/ _/ _/ _/ _/ Burlingame, CA 94010 ~~RECOM Technologies Inc.~~ Voice: 415.375.4265 FAX: 415.375.4490 From rem-conf-request@es.net Tue Mar 04 21:31:43 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Mar 1997 18:30:58 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id SAA00640; Tue, 4 Mar 1997 18:31:12 -0800 (PST) From: Dave Wright Message-Id: <199703050231.SAA00640@msri.org> X-Authentication-Warning: msri.org: smap set sender to using -f Received: from gauss.msri.org(198.129.65.58) by msri.org via smap (V1.3) id sma000631; Tue Mar 4 18:30:38 1997 Subject: Re: How to UNSUBSCRIBE from rem-conf To: ari@sprintlabs.com (Ari Ollikainen) Date: Tue, 4 Mar 1997 18:31:54 -0800 (PST) Cc: rem-conf@es.net In-Reply-To: from "Ari Ollikainen" at Mar 4, 97 06:03:26 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit You may also unsubscribe from the web at ... http://www.msri.org/mbone/ml.html : : I'm posting the following information as a public service: : : To UNSUBSCRIBE from the rem-conf list send your UNSUBSCRIBE : request (in both Subject: line and body of message) to: : : rem-conf-request@es.net : : The list maintainers do NOT read the messages sent to the whole : list. : : Back when I ran/maintained this list, I used to post a periodic : reminder for change requests and archive(s) location...I also : studiously ignored drop requests sent to the whole list unless : I had some time available to service them. : : Please do NOT send *me* any requests for changes...I've moved on... : : _/_/ _/_/_/_/ _/ Ari Ollikainen : _/ _/ _/ _/ _/ Sprint Advanced Technology Laboratories : _/_/_/_/ _/_/_/_/ _/ Switching and Interworking Development : _/ _/ _/ _/ _/ 1 Adrian Court (M/S: CABURS0102) : _/ _/ _/ _/ _/ Burlingame, CA 94010 : ~~RECOM Technologies Inc.~~ Voice: 415.375.4265 FAX: 415.375.4490 : : : ________ o Dave Wright _______ _/\_> dave@msri.org _______O=>// O 91CBR600F2 AFM# 316 -------------- Mathematical Sciences Research Institute From rem-conf-request@es.net Tue Mar 04 23:58:37 1997 Received: from sirius.ctr.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Mar 1997 20:57:42 -0800 Received: from orion (orion.ctr.columbia.edu [128.59.68.28]) by sirius.ctr.columbia.edu (8.8.5/8.6.4.287) with SMTP id XAA17014; Tue, 4 Mar 1997 23:57:35 -0500 (EST) Sender: liao@ctr.columbia.edu Message-ID: <331CFD3F.DF@ctr.columbia.edu> Date: Tue, 04 Mar 1997 23:57:35 -0500 From: Raymond Liao Organization: CTR, Columbia University X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: rem-conf@es.net CC: mnl@ctr.columbia.edu Subject: Comet Group Seminar: B. Badrinath, Rutgers Univ., "On Supporting an Internet Cellular Phone Network" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MBone Broadcast Announcement Title: ON SUPPORTING AN INTERNET CELLULAR PHONE NETWORK Speaker: Br. Badrinath Department of Computer Science, Rutgers University Date: Thursday, March. 06, 1997 Time: 12:00 NOON - 1:00 PM EST Multicast Address: audio: DVI, RTP, 224.2.194.51/21104 , ttl=127 video: H.261, RTP, 224.2.170.239/57392 , ttl=127 Contact: Andrew T. Campbell 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: Providing service guarantees in a mobile internetwork requires that the network account for host mobility. Host mobility imposes spatial resource demands on the network. In this talk, we will explore new service models, admission control policies, and spatial reservation schemes for mobile hosts in ISPN(Integrated Services Packet Network). We will also discuss aspects of MRSVP; a Mobile RSVP scheme to support applications requiring quality of service in a mobile internetwork. One such example: An internet cellular phone. -- Raymond R.-F. Liao (212) 939-7158 http://www.ctr.columbia.edu/~liao Center for Telecommunications Research, Columbia University From rem-conf-request@es.net Wed Mar 05 08:16:05 1997 Received: from shiva.jussieu.fr by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Mar 1997 05:15:29 -0800 Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id OAA18678 ; Wed, 5 Mar 1997 14:13:44 +0100 (MET) Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1]) by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id NAA01995 for ; Wed, 5 Mar 1997 13:49:07 +0100 (MET) Received: from mailer1.lut.ac.uk (mailhost.lut.ac.uk [158.125.1.202]) by soleil.uvsq.fr (8.8.5/jtpda-5.2) with SMTP id NAA16949 for ; Wed, 5 Mar 1997 13:48:58 +0100 (MET) Received: from sun-cc201.lboro.ac.uk [158.125.1.201] (root) by mailer1.lut.ac.uk with smtp (Exim 1.596 #1) id 0w2G7k-0000D2-00; Wed, 5 Mar 1997 12:48:48 +0000 Received: from [194.66.220.37] [194.66.220.37] by sun-cc201.lboro.ac.uk with smtp (Exim 1.596 #1) id 0w2G7h-00019Z-00; Wed, 5 Mar 1997 12:48:45 +0000 X-Sender: acno@hpcin.lboro.ac.uk Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: congres@prism.uvsq.fr From: N.Oloughlin@lcad.ac.uk (Niall O'Loughlin) Subject: 21N97 Date: Wed, 5 Mar 1997 12:48:45 +0000 I have just received part of a message about a call for papers but the important part is missing. Would you send the message again, please? Regards, Niall O'Loughlin Dr Niall O'Loughlin Loughborough College of Art and Design Epinal Way, Loughborough, Leicestershire LE11 3GE U.K. Telephone 01509-261515 ext 176 International +44-1509-261515 ext 176 Fax 01509-265515 International +44-1509-265515 e-mail: N.Oloughlin@lcad.ac.uk From rem-conf-request@es.net Wed Mar 05 12:48:17 1997 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Mar 1997 09:47:38 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 5 Mar 1997 17:47:28 +0000 To: rem-conf@es.net Subject: socks/mbone firewalls Date: Wed, 05 Mar 1997 17:47:26 +0000 Message-ID: <2466.857584046@cs.ucl.ac.uk> From: Jon Crowcroft in order to help some commercial intranet and ISP company managers feel happier about mbone deployment: can anyone point me at a discussion paper/description of firewall usage, multicast UDP and mbone applications, and any rationale as to a) attacks (e.g. denial of service esp., but usual service breakins and disclosure etc obviously useful too) b) defenses c) procedures for mbone app<->firewall auth etc etc thanks jon From rem-conf-request@es.net Wed Mar 05 16:28:51 1997 Received: from emout04.mail.aol.com (actually emout04.mx.aol.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Mar 1997 13:27:20 -0800 Received: (from root@localhost) by emout04.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0) id QAA10440 for rem-conf@es.net; Wed, 5 Mar 1997 16:27:04 -0500 (EST) Date: Wed, 5 Mar 1997 16:27:04 -0500 (EST) From: MADPR@aol.com Message-ID: <970305162702_2028873154@emout04.mail.aol.com> To: rem-conf@es.net Subject: Media Demos of Player-less Audio Broadcasting Vosaic Audio for Java, announced worldwide last week, will be exclusively demonstrated to the media at InternetWorld, Mar. 12-15, Los Angeles Convention Center. Highlights of the demonstration will include live radio broadcasting and individual audio streams on request. Vosaic Audio for Java is the first audio streaming system which runs without a proprietary player. Call Mitch Koppel or Allyson Stinchfield (312) 541-8787 or e-mail at mkoppel@msn.com to confirm an appointment for private demonstration in Press Suite Room 11. Copy of announcement release follows: ------------------------------------------------------------------------------ ------------------------------------------- CONTACTS: Mitch Koppel/ Phil Dunne MINKUS & DUNNE 312/ 541-8787 mkoppel@msn.com VOSAIC ANNOUNCES "VOSAIC AUDIO FOR JAVA" A revolutionary server-less, plug-in free, firewall-busting, Java-based sound streaming system for the Web FEBRUARY 26, 1997 (Chicago, IL) --- Vosaic L.L.C. today announced the introduction of what is believed to be the first pure Java-based sound streaming system using the global ITU standard, GSM audio, VOSAIC Audio for Java. It is a Java revolution in the making as it enables Web masters to easily include audio on their web pages and take advantage of Java's unique cross-platform capabilities. All major browsers are totally compliant; simply point and click on a VOSAIC Audio for Java enabled HTML web page and immediately listen to audio...no plug-ins to fuss with, no installation routines to screw up your machine. It is simply no-brainer, push-button, turn-on-the-radio simplicity to hear audio over the Net. "Vosaic has created an exciting new multimedia enhancement for the Web which I believe will become an important part of how we communicate globally," says Lana Coronado, Director of Worldwide Information Technology Services at CNNfn Interactive, a leading financial news network in New York City. "Music, news, teaching and training will become the staple of the Web and Vosaic's unique Java-based audio streaming system is a big step forward --- an ideal way to enhance anyone's Web site." The VOSAIC Audio for Java authoring tool is also revolutionary in its simplicity. Based on pure Java, it works on all platforms and makes use of the global ITU standards for sound, the GSM audio codec, into a universal audio sound source that is used in most of the world's cellular phone systems. The VOSAIC Audio for Java authoring tool takes the universally available WAV and AIFF files as sound sources and simply applies the built-in auto-conversion tool and GSM sound compressor to immediately generate VOSAIC Audio for Java compliant sound files for instant audio streaming over the Net. Once converted, simply add a simple HTML statement to the Web page and start streaming off any Web server immediately. "What Vosaic has done with this new technology has changed the entire business model for multimedia and the Internet. No longer is the installed base or number of plug-ins downloaded a factor. This VOSAIC Audio for Java is by far the easiest system there is to use. This is what multimedia and the Web should be and this is what is going to make the Web come alive...a paradigm shift for both Intra and Internets and the new broadcast ExtraNets (BxNets)," says Jeff Marshall, Senior Managing Director of Communications Technology at Bear, Stearns & Co, Inc., a leading investment firm on Wall Street. The VOSAIC Audio for Java sound streaming also provides tremendous value for money. For a limited time only, VOSAIC Audio for Java is FREE for downloading. Unlike other audio streaming systems, VOSAIC Audio for Java is a flat-rate, $ 249 each, UNLIMITED audio streaming system. "Web operators and content providers will no longer will feel constrained by other audio casters' usurious per-stream-pricing, dollars per hit or percent of revenue demands. They are now free to let audio be the universally accepted medium it was meant to be since the days of Marconi and BBC World radio", says Stuart Johnstone, CEO and co-founder of Vosaic L.L.C. "Vosaic sees the delivery of audio over the Web as the fundamental basis of global human communications. As such, we believe the delivery of audio should be a commodity, available to all ubiquitously and for the benefit of the planet. Look to Vosaic in the near future to deliver a number of exciting musical and special events in concert with content partners", states Johnstone. VOSAIC Audio for Java has the capability to punch through most known firewalls so that content creators/providers can be relatively confident that their message is punching through to the rest of the world. As GSM can be easily streamed through 28.8 modems, the world becomes the author's oyster. Coming soon---look out for VOSAIC Stereo for Java using Dolby Laboratories famous AC3 codec, known as DOLBY Net, and for VOSAIC Radio for Java, the unicasting, multicasting audio streaming system for "live" events. Vosaic L.L.C. is in the visual and audio IP-network telecommunications business and was founded in 1996 to research, develop, and commercialize technologies arising out of the University of Illinois's Systems Research Group (comprised of Digital Computer Labs and the NCSA). Vosaic L.L.C. is located at 1248 North Lake Shore Dr., Chicago, Il 60610, Phone +(312) 943-6764, FAX +(312) 943-6765 and on the web at . # # # Edior's Notes: - visit the Vosaic homepage to run the instant playing, streaming VOSAIC Audio for Java - call or E-mail or mkoppel@msn.com for evaluation software. - trademarks are properties of their respective trademark owners. (end) From rem-conf-request@es.net Wed Mar 05 17:14:23 1997 Received: from panda.nttlabs.com by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Mar 1997 14:13:39 -0800 Received: by panda.nttlabs.com (8.8.3/3.5W(96/10/22)) id OAA04469 for rem-conf@es.net; Wed, 5 Mar 1997 14:13:38 -0800 (PST) Date: Wed, 5 Mar 1997 14:13:38 -0800 (PST) From: Richard Core Message-Id: <199703052213.OAA04469@panda.nttlabs.com> To: rem-conf@es.net Subject: vic option needed (xmit at startup) X-Sun-Charset: US-ASCII I would like vic to be able to startup in Transmit mode. Anyone have or seen such a vic? A command line option would work nicely in my usage. Thanks, Richard From rem-conf-request@es.net Wed Mar 05 17:49:57 1997 Received: from yosemite.lbl.gov by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Mar 1997 14:49:27 -0800 Received: (from kamps@localhost) by yosemite.lbl.gov (8.7.3/8.7.3/NERSC-Feb96) id OAA04097; Wed, 5 Mar 1997 14:49:02 -0800 (PST) Date: Wed, 5 Mar 1997 14:49:02 -0800 (PST) From: Marcy Kamps Message-Id: <199703052249.OAA04097@yosemite.lbl.gov> To: kruse@nordicglobal.com Subject: Re: HELP Cc: rem-conf@es.net X-Sun-Charset: US-ASCII Holger, The rem-conf@es.net mailing list does not use listserv commands. What kind of help do you need from the rem-conf@es.net list maintainer? Thanks, Marcy L. Kamps ************************************************************************ National Energy Research Scientific Computing Center (NERSC) Energy Sciences Network (ESnet) Lawrence Berkeley National Laboratory Phone : 1-510-486-6448 One Cyclotron Road, Bldg. 50C, Room 103 (or) : 1-800-66-NERSC Berkeley, CA 94720 USA Email : kamps@nersc.gov Internet: postmaster@es.net ************************************************************************ ----- Begin Included Message ----- >From rem-conf-postmaster-request@es.net Wed Mar 5 07:58 PST 1997 To: rem-conf-request From: Holger Kruse Date: Wed, 05 Mar 1997 18:55:41 -0400 Reply-To: kruse X-Mailer: GoodNews 1.5 (Dec 28 1996) Subject: HELP Organization: Nordic Global Inc. Content-Type: text Content-Length: 90 HELP -- Holger Kruse kruse@nordicglobal.com http://www.nordicglobal.com ----- End Included Message ----- From rem-conf-request@es.net Wed Mar 05 18:09:32 1997 Received: from INET-05-IMC.microsoft.com (actually mail5.microsoft.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Mar 1997 15:08:46 -0800 Received: by INET-05-IMC with Internet Mail Service (5.0.1457.3) id ; Wed, 5 Mar 1997 15:07:32 -0800 Message-ID: <503A2A3C2932CF118D8800805FD44E1802BBD79B@RED-68-MSG> From: Eric Fleischman To: "'confctrl@isi.edu'" , "'rem-conf@es.net'" Subject: In Defense of Interleaved Data Formats Date: Wed, 5 Mar 1997 15:05:00 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) The list of reasons given in Section 5.2 of RFC 1889 as to why RTP sessions must be segregated by media type reminds me of a discussion I overheard a few years back. The one guy was saying "Trucks should be banned from the roadways. They are reckless, prone-to-overturn hazards belching out huge amounts of pollution. Their compression breaks cause deafness and their weight fosters the premature breakdown of the road surfaces..." At this point he lost me because I started to think about the implications of hauling manure, gravel, or plywood with cars. My brother-in-law, of course, does exactly that by using a specially constructed trailer made just for such purposes. But then, he gets stuck in some pretty pitiful places. Mind you, I'm not adverse to cars - I own one myself and use it for my daily commute. Similarly, I would gladly say "amen" in any praise meeting about the advantages of payload-segregated RTP traffic. I readily concur that this approach leads to some marvelously creative solutions for a wide variety of practical problems. I am actively interested in Van Jacobson's and Steve McCanne's "Receiver-driven Layered Multicast" research. Hey! I really do believe! Don't get me wrong: I'm all for cars! ... I just want to use my truck when it comes to hauling gravel. Separately encoded media RTP sessions are a marvelous solution to conferencing applications. They can also be used for "On-Demand" Streaming applications -- just like my brother-in-law can successfully haul gravel with his trailer. However, there are many occasions when "On-Demand Streaming" requires the use of interleaved data formats. Here's a few: 1. You can save substantial amount of overhead for sessions accessed by low speed modems. The argument here is that by interleaving, only one IP, UDP, and RTP header is used, instead of the X number of duplicate headers for each of the X media types. (Of course everything is packetized so this saving accumulates at a constant rate.) The counter-argument against this is that Van Jacobson's header compression can convert these extra headers down to the size of pinheads, saving even more than the original savings. Then the counter-argument to that counter-argument is that if you are spending that type of overhead (i.e., on-the-fly compression) to process your "on demand" application then the number of sessions you can simultaneously support on that server is detrimentally impacted. (Is this a ploy by high-end machine builders to sell more product or what?) 2. While some "on-demand" content is thrown together by chimpanzees, most of it is carefully crafted by artisans. For this reason, most on-demand streaming applications go to extraordinary lengths to ensure that the multimedia experience presented to the client is the identical multimedia experience which was designed by the content creator. Interleaving encourages tight synchronization and offers a higher degree of probability for preserving the designed experience in the presence of data loss, network variability, and sunspots. 3. On-demand media may be composed of many media types. Some of these are "streaming" media types (e.g., voice, video, and MIDI) while others are not (e.g., still images, URL flippings, script commands and executables). "On demand uses" also encourage the innovative invention of rare media types. Regardless, the net effect is that there will be N media streams for on-demand usages where N may be quite a handful. Interleaving permits these many media streams to be presented in a harmonious, orchestrated and optionally synchronized fashion. While this is an expansion on the previous point, it also seeks to highlight that conferencing and "on-demand" uses are quite different when it comes to range of media which must be coordinated and the variability and precision demanded for controlling the interaction between these media types. 4. Disk-head movement efficiency on the server. The argument here is that interleaving encourages more efficient disk storage approaches with superior I/O processing capabilities. This directly effects the construction of more efficient network streaming approaches. This efficiency directly translates into server performance including the ability to support a larger number of simultaneous "On-demand" sessions by that server. I own both a truck and a car. I similarly want to use media segregated streams over RTP in environments where it makes sense to do so and to use interleaved data streams over RTP in environments where it makes sense to do so. One exciting aspect of the current RTSP proposal is that it should theoretically permit both approaches to be carried over RTP. Traditional RTP traffic can be carried in the traditional way. Interleaved data traffic can be supported via encapsulating the media definitions (e.g., the information contained within an ASF or RMFF header) which can be obtained by an RTSP "get" command. A dynamic RTP payload type value can then be associated with that header information for that session. The ASF or RMFF data can then be "streamed" via RTP and interpreted correctly. From rem-conf-request@es.net Wed Mar 05 18:42:41 1997 Received: from panda.nttlabs.com by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Mar 1997 15:41:28 -0800 Received: by panda.nttlabs.com (8.8.3/3.5W(96/10/22)) id PAA04719; Wed, 5 Mar 1997 15:41:23 -0800 (PST) Date: Wed, 5 Mar 1997 15:41:23 -0800 (PST) From: Richard Core Message-Id: <199703052341.PAA04719@panda.nttlabs.com> To: DAAgarwal@lbl.gov Subject: vic transmitOnStartup (NeverMind!) Cc: vic@ee.lbl.gov, rem-conf@es.net X-Sun-Charset: US-ASCII Never mind... just found "yesno transmitOnStartup" and the -X resource=value arg I'm feeling foolish... Thanks, Richard From rem-conf-request@es.net Wed Mar 05 19:39:27 1997 Received: from buttle.lcs.mit.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Mar 1997 16:37:53 -0800 Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4) id TAA08948; Wed, 5 Mar 1997 19:36:18 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Eric Fleischman cc: "'confctrl@isi.edu'" , "'rem-conf@es.net'" Subject: Re: In Defense of Interleaved Data Formats In-reply-to: Your message of "Wed, 05 Mar 1997 15:05:00 PST." <503A2A3C2932CF118D8800805FD44E1802BBD79B@RED-68-MSG> Date: Wed, 05 Mar 1997 19:36:18 -0500 Message-ID: <8946.857608578@buttle.lcs.mit.edu> Sender: mjh@buttle.lcs.mit.edu >The list of reasons given in Section 5.2 of RFC 1889 as to why RTP >sessions must be segregated by media type reminds me... ... >However, there are many occasions when >"On-Demand Streaming" requires the use of interleaved data formats. >Here's a few: >1. You can save substantial amount of overhead for sessions >accessed by low speed modems. ... >(i.e., on-the-fly compression) to process your "on demand" application >then the number of sessions you can simultaneously support on that >server is detrimentally impacted. Note that header compression is not end-to-end, but only between your end-system and its local terminal server. It doesn't impact multimedia data servers at all. >2. ... Interleaving encourages tight synchronization and offers a >higher degree of probability for preserving the designed experience in >the presence of data loss, network variability, and sunspots. Actually this isn't true. Interleaving gives the network less oportunity to preserve your audio preferentially from your video if the network gets loaded (which is usually the right thing to do). In addition, synchronisation is no easier. You have all the same information in separate RTP streams that you have in interleaved streams. In either case you need to cope with mismatches in clock rate between the video stream and a receiving audio device that which is not clocked at exactly the frequency the manufacturer claims. Once you're re-tuning the audio buffering periodically, it makes no difference whether the streams were transported together or separately. >3. On-demand media may be composed of many media types. Some of >these are "streaming" media types (e.g., voice, video, and MIDI) while >others are not (e.g., still images, URL flippings, script commands and >executables). "On demand uses" also encourage the innovative invention >of rare media types. Regardless, the net effect is that there will be N >media streams for on-demand usages where N may be quite a handful. This seems to be an argument *against* interleaving to me... >4. Disk-head movement efficiency on the server. The argument here >is that interleaving encourages more efficient disk storage approaches >with superior I/O processing capabilities. This directly effects the >construction of more efficient network streaming approaches. Separate streams lets you store your audio and video on different discs, and hence *improves* performance in some cases :-) Besides, if your server isn't doing some form of tuning to available bandwidth, it's going to be a dinosaur in the long run. Right now you might get away with it but the internet won't stand large numbers of unadaptive streams, and so we'll get schemes like RED, CBQ, WFQ, etc deployed to defend it. Once the server is doing bandwidth adaption of such streams, I don't really believe that the "interleaving impacts the disc" argument holds well because you'll likely be using layered codecs anyway. At the very least, you won't be able to stream straight from disc to net. Mark From rem-conf-request@es.net Wed Mar 05 21:51:12 1997 Received: from INET-05-IMC.microsoft.com (actually mail5.microsoft.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Mar 1997 18:49:48 -0800 Received: by INET-05-IMC with Internet Mail Service (5.0.1457.3) id ; Wed, 5 Mar 1997 18:52:00 -0800 Message-ID: <503A2A3C2932CF118D8800805FD44E1802BBD79F@RED-68-MSG> From: Eric Fleischman To: 'Mark Handley' Cc: "'confctrl@isi.edu'" , "'rem-conf@es.net'" Subject: RE: In Defense of Interleaved Data Formats Date: Wed, 5 Mar 1997 18:46:43 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Your comments appear to be written from a conferencing perspective. I fear that I haven't helped you to understand the fundamental requirement of a significant percentage (i.e., probably the majority) of "on demand" usage. This requirement is that the "multimedia experience" is preserved independently of what is happening on the network. Thus, if the network becomes saturated, the worst thing to do would be to drop a given media stream in order to preserve another stream based on network assumptions as to which stream may be "more important" (i.e., your suggestion to drop video but to preserve audio in a congested situation). This incorrectly presumes that one media type is more important than another in a "multimedia experience". They all are important if the "experience" is to be maintained in tact. Now mind you, the content creator may indeed choose for certain streams to be given preferential treatment but it is simply impossible to know which stream will be given such preference in the general case - unlike the conferencing experience. Rather, the appropriate thing to do in the face of severe network congestion would be to do one of the following: * Cancel the experience outright due to underlying network problems * Delay the experience until such a time as the network can handle the load * Continue the experience with "choppy" reception Thus, as you can see, interleaving is the most appropriate approach for preserving a multimedia experience since it is more difficult to manage an appropriate response with segregated media streams and they are more prone to distort the experience in the face of network congestion. It is doubtful that you will be able to understand what I'm talking about as long as you think as an engineer. I am talking "experience" not "information". This is a left-brain, right-brain type of dichotomy. To understand what I'm saying, you have to think as an artist. What we are talking about is the preservation of an artistic creation across the network. That this creation may educate or convey critical, essential information does not diminish the fact that we are talking about art-forms when we are talking about "on demand" streaming. I therefore encourage you to re-read my original message from this point-of-view. Should you do so, then I think that you will find points 2-4 to be very intuitive and obvious. I thank you for your input about point #1 since that was information about which I was previously unaware. Also, you seem to be thinking only about audio and video when I say "multimedia". While interesting experiences are indeed created using only those two media types, I would prefer you to think of audio + video + MIDI + URL flipping + streaming text + active background applications like stock tickers + still images + .... Why limit ourselves to only two media types? Certainly the people making streaming "on-demand" content don't. I implied in my original message that there were many reasons supporting interleaving of data, even though I only cited four. Here's another (and, if you keep disagreeing with me, I'll have to keep giving other reasons ;-) ): When the artist creates the multimedia experience, the artist creates that experience independent from any underlying network concerns (in the general case) with the sole exception of data rates. The experience is indeed targeted to be streamed at a given data rate and that rate constrains how much data is available at any point of the timeline. The artist doesn't care in many cases whether the experience is carried over RTP or whether it is carried via TCP, UDP, or HTTP, IPX/SPX, SNA, or whatever just as long as it arrives as designed. Now you will perhaps argue that streaming content can't be carried over connection-oriented transports like the TCP or HTTP such as were mentioned in the previous sentence. Experience has demonstrated that this observation may very well be true for segregated media streams, however, it is emphatically *not* true for interleaved media streams (given a certain preroll value). Here's the deal: the content creator determines the experience but the local client's environment determines the mechanism by which that experience is delivered. When we made our product, therefore, we were compelled to de-couple the experience from the transport. This means that any given experience will need to be carried via RTP here but HTTP there. Why HTTP and why native TCP? Well, it turns out that many users are very concerned about their firewalls with the degree of concern varying between companies. Some corporations will permit us to "bore through" their firewalls via a UDP session, others will permit a single port via TCP streaming, while others refuse to permit any holes in their firewalls whatsoever. In the latter case we stream via HTTP if they permit that protocol to enter their environment, otherwise we are blocked out. -----Original Message----- From: Mark Handley [SMTP:mjh@isi.edu] Sent: Wednesday, March 05, 1997 4:36 PM To: Eric Fleischman Cc: 'confctrl@isi.edu'; 'rem-conf@es.net' Subject: Re: In Defense of Interleaved Data Formats Your comments appear to be written from a conferencing perspective. They don't seem to understand the fundamental requirements of a significant percentage of "on demand" usage. This requirement is that the "multimedia experience" is preserved independently of what is happening on the network. Thus, if the network becomes saturated, the absolutely wrong thing to do would be to drop a given media stream to preserve another stream (i.e., your suggestion to drop video but to preserve audio in a congested situation). Rather, the appropriate thing to do would be to do one of the following: >2. ... Interleaving encourages tight synchronization and offers a >higher degree of probability for preserving the designed experience in >the presence of data loss, network variability, and sunspots. Actually this isn't true. Interleaving gives the network less oportunity to preserve your audio preferentially from your video if the network gets loaded (which is usually the right thing to do). In addition, synchronisation is no easier. You have all the same information in separate RTP streams that you have in interleaved streams. In either case you need to cope with mismatches in clock rate between the video stream and a receiving audio device that which is not clocked at exactly the frequency the manufacturer claims. Once you're re-tuning the audio buffering periodically, it makes no difference whether the streams were transported together or separately. >3. On-demand media may be composed of many media types. Some of >these are "streaming" media types (e.g., voice, video, and MIDI) while >others are not (e.g., still images, URL flippings, script commands and >executables). "On demand uses" also encourage the innovative invention >of rare media types. Regardless, the net effect is that there will be N >media streams for on-demand usages where N may be quite a handful. This seems to be an argument *against* interleaving to me... >4. Disk-head movement efficiency on the server. The argument here >is that interleaving encourages more efficient disk storage approaches >with superior I/O processing capabilities. This directly effects the >construction of more efficient network streaming approaches. Separate streams lets you store your audio and video on different discs, and hence *improves* performance in some cases :-) Besides, if your server isn't doing some form of tuning to available bandwidth, it's going to be a dinosaur in the long run. Right now you might get away with it but the internet won't stand large numbers of unadaptive streams, and so we'll get schemes like RED, CBQ, WFQ, etc deployed to defend it. Once the server is doing bandwidth adaption of such streams, I don't really believe that the "interleaving impacts the disc" argument holds well because you'll likely be using layered codecs anyway. At the very least, you won't be able to stream straight from disc to net. Mark From rem-conf-request@es.net Wed Mar 05 22:17:43 1997 Received: from comsun.comm.toronto.edu (actually comsun.comm.utoronto.ca) by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Mar 1997 19:16:50 -0800 Received: from jupiter ([128.100.244.3]) by comsun.comm.toronto.edu with SMTP id <34133>; Wed, 5 Mar 1997 22:16:38 -0500 Sender: keith@comm.toronto.edu Message-ID: <331E36FA.6793@nal.utoronto.ca> Date: Wed, 5 Mar 1997 22:16:10 -0500 From: Keith Chow Organization: University of Toronto X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: rem-conf@es.net Subject: Problem making vic-2.8 on Solaris 2.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi there, I have a problem making vic-2.8 on Solaris 2.5.1 as follows: ld: fatal: symbol `TkPlatformInit' is multiply defined: (file main.o and file /usr/local/lib/libtk4.1.a(tkUnixInit.o)); ld: warning: symbol `random' has differing types: (file random.o type=NOTY; file /usr/lib/libc.so type=FUNC); random.o definition taken ld: fatal: File processing errors. No output written to vic gmake: *** [vic] Error 1 Can anybody give me a help? Thanks in advance. Keith. -- ----------------------------------------------- Keith HungKei Chow Network Architecture Lab, Communication Group, Department of Electrical & Computer Engineering University of Toronto Ontario, Canada. Tel: (416) 978-1611 Fax: (416) 978-4425 Email: keith@nal.utoronto.ca keith@comm.utoronto.ca ----------------------------------------------- From rem-conf-request@es.net Thu Mar 06 00:58:49 1997 Received: from proxy2.ba.best.com by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Mar 1997 21:57:55 -0800 Received: from mg128-204.ricochet.net (mg128-204.ricochet.net [204.179.128.204]) by proxy2.ba.best.com (8.8.5/8.8.3) with SMTP id VAA29773; Wed, 5 Mar 1997 21:54:48 -0800 (PST) Date: Wed, 5 Mar 1997 21:54:48 -0800 (PST) Message-Id: <1.5.4.16.19970305223954.0a076550@pop.best.com> X-Sender: rsf@pop.best.com X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Eric Fleischman From: Ross Finlayson Subject: Re: In Defense of Interleaved Data Formats Cc: "'confctrl@isi.edu'" , "'rem-conf@es.net'" At 03:05 PM 3/5/97 -0800, Eric Fleischman wrote: >4. Disk-head movement efficiency on the server. The argument here >is that interleaving encourages more efficient disk storage approaches >with superior I/O processing capabilities. This directly effects the >construction of more efficient network streaming approaches. This >efficiency directly translates into server performance including the >ability to support a larger number of simultaneous "On-demand" sessions >by that server. Let's not forget that we're designing network protocols here, not storage formats. There's nothing to preclude the various media that make up a multimedia session being interleaved on the *disk*, even though the data within each of the resulting network packets is not interleaved. (In fact, one can even imagine a media server storing its data with partially precomputed network headers, to optimize the process of spitting its data out onto the network.) Incidentally, this confusion - between storage formats and network data formats - is one that I've seen recently occur in other IETF working groups, e.g., the "calendar scheduling" group. Microsoft (& other companies) are free to continue to define and use whatever storage formats they wish. We don't care; this is the *Internet* Engineering Task Force. All we care about is what goes over the network. In your follow-up message, you wrote: >It is doubtful that you will be able to understand what I'm talking >about as long as you think as an engineer. I am talking "experience" not >"information". This is a left-brain, right-brain type of dichotomy. To >understand what I'm saying, you have to think as an artist. What we are >talking about is the preservation of an artistic creation across the >network. That this creation may educate or convey critical, essential >information does not diminish the fact that we are talking about >art-forms when we are talking about "on demand" streaming. I'm sorry to sound rude, but this "touchy-feely" stuff makes me want to vomit. This is the Internet *Engineering* Task Force, and *engineering* is what we do here. Fortunately, there *are* some real engineering questions that arises from your concerns, namely: You want it to be possible to implement one of the following end-to-end semantics when confronted with network loss or delay: 1/ cancel the presentation 2/ delay the presentation (as appropriate) 3/ continue the presentation in spite of missing data The questions are: a) Can the particular choice (between 1, 2 and 3) be adequately conveyed - e.g., in a session description - if different media are *not* interleaved within network packets. b) Can each of these choices be implemented (efficiently), if different media are *not* interleaved within network packets. We should, I think, be able to answer these questions without having to stick our heads inside a pyramid. Ross. From rem-conf-request@es.net Thu Mar 06 03:15:40 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Mar 1997 00:14:41 -0800 Received: from big-bear by precept.com (SMI-8.6/SMI-SVR4) id AAA02744; Thu, 6 Mar 1997 00:01:27 -0800 Date: Thu, 6 Mar 1997 00:01:27 -0800 (PST) From: Karl Auerbach X-Sender: karl@big-bear Reply-To: karl@precept.com To: Eric Fleischman cc: 'Mark Handley' , "'confctrl@isi.edu'" , "'rem-conf@es.net'" Subject: RE: In Defense of Interleaved Data Formats In-Reply-To: <503A2A3C2932CF118D8800805FD44E1802BBD79F@RED-68-MSG> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII You are arguing that interleaved representations are necessary to preserve "the multimedia experience". And further that the ability of a non-interleaved, packet-per-media type approach to suppress one of the media types of the presentation isn't useful because it would destroy "the multimedia experience". You seem to be saying that it is better to simply stop the presentation, in total, rather than try to carry any less than perfect rendition. I don't agree. The choice depends on the type of presentation. When reality strikes, we will notice that a lot of presentations happen to be audio and video presentations or conferences (often with less than stellar camera work or microphone mixing -- hardly an artistic creation.) And our own experience has tought us that there are techniques, such as layered encodings and the like, which can preserve the intelligibility of the interchange at the cost of some audio quality or even the video itself. Interleaved streams will prevent us from making use of those techniques on those sessions where quality degredation is not only acceptable, but is desiragle to preserve the information content. And on those presentations in which one wants to stop the data flow or postpone it, whether the data is interleaved or not really makes no difference. It's just as easy to tell a server to stop sending two separate RTP streams as it is to tell it to stop one. And as someone mentioned, the argument for interleaving avoids dealing with the fact that inside a receiving computer, the audio and video paths are very different and have different time delays. So the data streams will be separated and independently timed for rendition no matter whether they arrive in the same or different packets. So even if I were to agree with you that total quality must not be sacrificed, I still don't agree with you that that leads to the conclusion that one must have interleaved streams. > It is doubtful that you will be able to understand what I'm talking > about as long as you think as an engineer. Speaking as one who spends a lot of my time doing live theatre, I wouldn't be so quick to deprecate the ability of engineers to comprehend aesthetic issues. OK, I'm sitting here pretending that I'm on-stage looking into the lights and hearing the rustle of the audience while I'm waiting for the music cue... .... .... Whew, that was one artistic experience! ... And I still don't agree with you. > ... Now you will perhaps > argue that streaming content can't be carried over connection-oriented > transports like the TCP or HTTP such as were mentioned in the previous > sentence. Experience has demonstrated that this observation may very > well be true for segregated media streams, however, it is emphatically > *not* true for interleaved media streams (given a certain preroll > value). Of course "streaming content" can be carried over connection-oriented transports like TCP. Just not in real-time. TCP engines are designed with various algorithms to avoid adding to network congestion. As such they exhibit potentially long, possibly difficult to bound, delays. Unless you know the characteristics of the TCP engines involved, you can't come up with a completely safe "preroll" value. There is always a chance that you will underrun. Your comments about firewalls are well taken. However, I have faith that the firewall folks can figure out how to deal with UDP based traffic. --karl-- From rem-conf-request@es.net Thu Mar 06 03:25:18 1997 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Mar 1997 00:24:27 -0800 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id AAA00379; Thu, 6 Mar 1997 00:24:14 -0800 (PST) Message-Id: <199703060824.AAA00379@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Mark Handley cc: Eric Fleischman , "'confctrl@isi.edu'" , "'rem-conf@es.net'" Subject: Re: In Defense of Interleaved Data Formats In-reply-to: Your message of "Wed, 05 Mar 1997 19:36:18 EST." <8946.857608578@buttle.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Mar 1997 00:24:14 -0800 From: Amancio Hasty >From The Desk Of Mark Handley : > >4. Disk-head movement efficiency on the server. The argument here > >is that interleaving encourages more efficient disk storage approaches > >with superior I/O processing capabilities. This directly effects the > >construction of more efficient network streaming approaches. > > Separate streams lets you store your audio and video on different > discs, and hence *improves* performance in some cases :-) Well, sort of ... If you are going to have a server I would imagine that one can do software or hardware disk stripping , if such is the case then perhaps an interleave media stream is more efficient than two different media streams. If one media stream requires more bandwidth than the other then it may be nice to have separate streams for a better system utilization by transmitting the prioritized stream. I would imagine that the best way of handling interleaving vs. separate media streams is to leave the choice to the tool and not mandate it as a protocol procedure. Cheers, Amancio From rem-conf-request@es.net Thu Mar 06 04:16:15 1997 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Mar 1997 01:15:21 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 6 Mar 1997 09:13:46 +0000 To: Ross Finlayson cc: Eric Fleischman , "'confctrl@isi.edu'" , "'rem-conf@es.net'" Subject: Re: In Defense of Interleaved Data Formats In-reply-to: Your message of "Wed, 05 Mar 1997 21:54:48 PST." <1.5.4.16.19970305223954.0a076550@pop.best.com> Date: Thu, 06 Mar 1997 09:13:44 +0000 Message-ID: <1148.857639624@cs.ucl.ac.uk> From: Jon Crowcroft >You want it to be possible to implement one of the following end-to-end >semantics when confronted with network loss or delay: > 1/ cancel the presentation > 2/ delay the presentation (as appropriate) > 3/ continue the presentation in spite of missing data >The questions are: >a) Can the particular choice (between 1, 2 and 3) be adequately conveyed - >e.g., in a session description - if different media are *not* interleaved >within network packets. >b) Can each of these choices be implemented (efficiently), if different >media are *not* interleaved within network packets. yes, well said... actually, what interleaving says is : It is a REQUIREMENT of this type of presentation that all media suffer network effects exactly in proportion to the way they are interleaved.... since this is pretty arbitrary compared with the way the QUALITY of the presentation will then vary (e.g. consider a variation in rate or loss for video versus a variance in audio for a given relative sample size in the packet), i suspect most content providers would be fairly upset by the way such a presentaiton would degrade...... interleaving: lets see now, what was the end2end principle again? >We should, I think, be able to answer these questions without having to >stick our heads inside a pyramid. :-) jon From rem-conf-request@es.net Thu Mar 06 07:55:05 1997 Received: from sumo.vocaltec.co.il by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Mar 1997 04:53:55 -0800 Received: from maskit1.vocaltec.co.il (patish.vocaltec.co.il [199.203.72.3]) by sumo.vocaltec.co.il (8.6.12/8.6.12) with SMTP id OAA12999 for ; Thu, 6 Mar 1997 14:51:18 +0200 From: Scott_Petrack@vocaltec.com Received: by maskit1.vocaltec.co.il(Lotus SMTP MTA v1.05 (274.9 11-27-1996)) id 42256452.0046C3E3 ; Thu, 6 Mar 1997 14:52:56 +0200 X-Lotus-FromDomain: VOCALTEC To: rem-conf@es.net Message-ID: <42256452.00420601.00@maskit1.vocaltec.co.il> Date: Thu, 6 Mar 1997 14:52:50 +0200 Subject: RE: In Defense of Interleaved Data Formats Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Scott Petrack 03/06/97 02:52 PM I would like to understand if there is any issue here which actually affects the specification of RTP or requires the intervention of AVT in any way. I claim that there is not. If the issue is merely "hey guys, interleaved formats are better. Really" then I think that the thread should be stopped, because I know of no horse in the entire AVT/MMUSIC realm which is more dead. Despite the use of the words "interleaving", there is no real desire to interleave currently defined RTP audio and RTP video packets within a single RTP session. What is desired is to have a single RTP session which contains packet after packet of new special beautifully crafted payloads. As far as the RTP spec is concerned, all that you need to do is to write an "RTP profile for the XXYYZZ media type". This will satisfy the RTP spec (that is, it will allow you to say "our server confirms to the Internet standard") and the only penalty will be that it will be "disallowed" to mix packets of "audio" or "video" media type with packets of the new XXYYZZ media types. But you weren't planning to do this anyway. To put it most simply - You don't need a change in the RTP spec to do what you want to do. You need to go and write a new profile and payload format. No amount of dickey-ing with the words in the spec will alter the fact that what you do will not be interoperable with applications which conform to the current profile for basic audio and video. This is not due to the lack of artistic sentiment on the part of the application writers - it is due to the fact that you have yet to invent the new media types, define payload formats and a profile for the RTP, and share this information with the rest of us. Once this is done, who knows? Maybe you'll convince people that your profile is more suitable for a particular purpose. Maybe. Until that time, I'll have to remind you that: "Wer sich der Einsamkeit ergibt, Ach! der is bald allein." (sorry, I was carried away by artistic inspiration) Scott From rem-conf-request@es.net Thu Mar 06 08:06:05 1997 Received: from cs.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Mar 1997 05:05:28 -0800 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id IAA14114; Thu, 6 Mar 1997 08:05:24 -0500 (EST) Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id IAA09997; Thu, 6 Mar 1997 08:05:23 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <331EC113.4E09@cs.columbia.edu> Date: Thu, 06 Mar 1997 08:05:23 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: rem-conf@es.net CC: confctrl@isi.edu Subject: Re: In Defense of Interleaved Data Formats References: <1148.857639624@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It should be pointed out that we had this same discussion many moons ago, on the rem-conf list, at least once. Note that there is one interleaved MPEG format (Civanlar) already. -- Henning Schulzrinne email: schulzrinne@cs.columbia.edu Dept. of Computer Science phone: +1 212 939-7042 Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs From rem-conf-request@es.net Thu Mar 06 11:22:36 1997 Received: from INET-04-IMC.microsoft.com (actually mail4.microsoft.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Mar 1997 08:21:59 -0800 Received: by INET-04-IMC.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC2A07.BB0DE940@INET-04-IMC.microsoft.com>; Thu, 6 Mar 1997 08:23:55 -0800 Message-ID: From: Eric Fleischman To: "'Scott_Petrack@vocaltec.com'" , "'rem-conf@es.net'" Subject: RE: In Defense of Interleaved Data Formats Date: Thu, 6 Mar 1997 08:17:46 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 96 TEXT Thank you, Scott, for your posting. I am not interested in amending the text of RFC 1889. Rather, I am interested in amending the text of the RTSP draft and hence will pursue this interest within mmusic and not bother avt further. My goal in bothering avt to date was to determine the sentiment within avt concerning a two prong use of RTP within the auspices of RTSP: 1) Short term stream interleaved content over RTP via using a dynamic payload type established for that session via an RTSP "get" command. 2) Medium/Long term define a generic RTP profile and payload format for a class of streaming interleaved data. Your response satisfies both of these goals. Therefore, if it represents the generic opinion of the avt group then I will be most content to return to silence and not trouble you further. Thanks for the poetry. Let's hope that you "wax artistic" frequently. BTW: A 6th argument to support interleaved data is that most existing multimedia data file formats (solely) support interleaved data if multiple media types are present. Thus, if one is to directly stream data from those files the most efficient way is to do so via interleaved data streams. -----Original Message----- From: Scott_Petrack@vocaltec.com [SMTP:Scott_Petrack@vocaltec.com] Sent: Thursday, March 06, 1997 4:53 AM To: rem-conf@es.net Subject: RE: In Defense of Interleaved Data Formats Scott Petrack 03/06/97 02:52 PM I would like to understand if there is any issue here which actually affects the specification of RTP or requires the intervention of AVT in any way. I claim that there is not. If the issue is merely "hey guys, interleaved formats are better. Really" then I think that the thread should be stopped, because I know of no horse in the entire AVT/MMUSIC realm which is more dead. Despite the use of the words "interleaving", there is no real desire to interleave currently defined RTP audio and RTP video packets within a single RTP session. What is desired is to have a single RTP session which contains packet after packet of new special beautifully crafted payloads. As far as the RTP spec is concerned, all that you need to do is to write an "RTP profile for the XXYYZZ media type". This will satisfy the RTP spec (that is, it will allow you to say "our server confirms to the Internet standard") and the only penalty will be that it will be "disallowed" to mix packets of "audio" or "video" media type with packets of the new XXYYZZ media types. But you weren't planning to do this anyway. To put it most simply - You don't need a change in the RTP spec to do what you want to do. You need to go and write a new profile and payload format. No amount of dickey-ing with the words in the spec will alter the fact that what you do will not be interoperable with applications which conform to the current profile for basic audio and video. This is not due to the lack of artistic sentiment on the part of the application writers - it is due to the fact that you have yet to invent the new media types, define payload formats and a profile for the RTP, and share this information with the rest of us. Once this is done, who knows? Maybe you'll convince people that your profile is more suitable for a particular purpose. Maybe. Until that time, I'll have to remind you that: "Wer sich der Einsamkeit ergibt, Ach! der is bald allein." (sorry, I was carried away by artistic inspiration) Scott From rem-conf-request@es.net Thu Mar 06 11:44:06 1997 Received: from INET-05-IMC.microsoft.com (actually mail5.microsoft.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Mar 1997 08:43:28 -0800 Received: by INET-05-IMC with Internet Mail Service (5.0.1457.3) id ; Thu, 6 Mar 1997 08:38:58 -0800 Message-ID: <503A2A3C2932CF118D8800805FD44E1802BBD7A6@RED-68-MSG.dns.microsoft.com> From: Eric Fleischman To: 'Jon Crowcroft' , Ross Finlayson Cc: "'confctrl@isi.edu'" , "'rem-conf@es.net'" Subject: RE: In Defense of Interleaved Data Formats Date: Thu, 6 Mar 1997 08:36:33 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Your point >It is a REQUIREMENT of this type of presentation that all media suffer >network effects exactly in proportion to the way they are interleaved.... is right on the mark. However, your follow-on comment isn't. Because "on demand" content isn't constructed in "real time", we have been able to give attention to implementing error mitigation (error discovery, error hiding, error correction) approaches within our data streams. We could certainly benefit from your considerable expertise in improving our current implementation of forward error correction. Might you be interested in pursuing this issue "off line" with us? From rem-conf-request@es.net Thu Mar 06 12:12:22 1997 Received: from venus.Sun.COM by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Mar 1997 09:11:23 -0800 Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA28349 for ; Thu, 6 Mar 1997 09:11:22 -0800 Received: from valathar.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA03202; Thu, 6 Mar 1997 09:11:20 -0800 Received: by valathar.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16436; Thu, 6 Mar 1997 09:11:07 -0800 Date: Thu, 6 Mar 1997 09:11:07 -0800 From: Michael.Speer@Eng.Sun.COM (Michael F. Speer) Message-Id: <199703061711.JAA16436@valathar.eng.sun.com> To: rem-conf@es.net Subject: Sunergy #25 Broadcast Cc: Michael.Speer@Eng.Sun.COM Folks: Due some technical problems, I will be arranging to re-broadcast this Sunergy for late next week. Sorry for the technical difficulties. Michael From rem-conf-request@es.net Thu Mar 06 18:56:14 1997 Received: from broon.off.connect.com.au by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Mar 1997 15:55:32 -0800 Received: from connect.com.au (ggm@localhost) by broon.off.connect.com.au with ESMTP id JAA21264 (8.8.5/IDA-1.6); Fri, 7 Mar 1997 09:55:10 +1000 (EST) X-Authentication-Warning: broon.off.connect.com.au: ggm owned process doing -bs To: Jon Crowcroft cc: rem-conf@es.net Subject: Re: socks/mbone firewalls In-reply-to: Your message of "Wed, 05 Mar 1997 17:47:26 GMT." <2466.857584046@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Mar 1997 09:55:05 +1000 Message-ID: <21263.857692505@connect.com.au> From: George Michaelson Didn't this get discussed on the list about 3 years ago? a well archived copy might find some of this. Maybe it took place live on the mbone and not via email (another reason audio is at a disadvantage compared to the written word) Bellovin & Cheswick has about 10 references in ther index BTW. -George From rem-conf-request@es.net Thu Mar 06 19:12:16 1997 Received: from nobozo.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Mar 1997 16:11:33 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id QAA19540; Thu, 6 Mar 1997 16:11:29 -0800 Date: Thu, 6 Mar 1997 16:11:29 -0800 Message-Id: <199703070011.QAA19540@nobozo.CS.Berkeley.EDU> X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: 298-list@bmrc.Berkeley.EDU, rem-conf@es.net From: Jerrlyn Iwata Subject: Berkeley Multimedia & Graphics Seminar Berkeley Multimedia and Graphics Seminar (Wednesday March 12, 1997 12:30-2:00 PDT 405 Soda Hall) "Interactive Commerce: Technology Solutions for Business on the Web" Pia Chamberlain Connect, Inc. Conducting business on the web generates challenges not encountered by static content providers. OneServer(tm), an internet commerce application technology platform offered by Connect, Inc., provides a comprehensive, integrated solution set to address these challenges, including transacted data access, integrated text search, an object-relational database back-end, usage tracking, Java integration, and sophisticated access control capabilities. I will present an architectural overview of OneServer(tm), briefly discussing how its capabilities support the creation of high-end internet commerce applications. Connect, Inc. has openings for CS/CE graduates for systems, application and quality assurance engineering positions. Please send resumes to Pia Chamberlain. -------------------------------------------------------------------------------- This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40 PDT (GMT - 8 hrs). See sdr or http://bmrc.berkeley.edu/298 for instructions on setting up, connecting to, and operating the MBONE tools. Please direct all technical questions to davesimp@cs.berkeley.edu From rem-conf-request@es.net Fri Mar 07 10:49:50 1997 Received: from mailcom.videoconferencing.com by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Mar 1997 07:49:07 -0800 Received: by mailcom.videoconferencing.com with Microsoft Exchange (IMC 4.0.837.3) id <01BC2AE5.43393030@mailcom.videoconferencing.com>; Fri, 7 Mar 1997 10:49:42 -0500 Message-ID: X-MS-TNEF-Correlator: From: Matthew Feldman To: "'rem-conf@es.net'" Subject: IETF e-mails Date: Fri, 7 Mar 1997 10:48:41 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Encoding: 11 TEXT, 35 UUENCODE X-MS-Attachment: WINMAIL.DAT 0 00-00-1980 00:00 Why I am always getting copies of the same e-mail constantly. Is there a problem with the rem-conf e-mail reflector? Can someone fix this problem? Is there a problem? Matthew Feldman CTO Intelect Visual Communications (212) 317-9600 begin 600 WINMAIL.DAT M>)\^(BL/`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$(@ <` M& ```$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`06 `P`.````S0<#``<` M"@`P`"D`!0!&`0$@@ ,`#@```,T'`P`'``H`, `I``4`1@$!"8 !`"$````Q M.#)!.#%%0T0V.39$,#$Q.38P1# P,# X-C Q-SA#-P#G!@$-@ 0``@````(` M`@`!!( !``T```!)151&(&4M;6%I;',`\ ,!`Y &`+0$```:`````P`N```` M``! `#D`T*FS!P\KO $>`' ``0```"<```!);B!$969E;G-E(&]F($EN=&5R M;&5A=F5D($1A=&$@1F]R;6%T``@0`0```&4```!7 M2%E)04U!3%=!65-'151424Y'0T]024533T942$5304U%12U-04E,0T].4U1! M3E1,64E35$A%4D5!4%)/0DQ%35=)5$A42$5214TM0T].1D4M34%)3%)%1DQ% M0U1/4C]#04Y3``````,`$! ``````P`1$ `````"`0D0`0```&L!``!G`0`` M60(``$Q:1G5&L(;6_P`*`0\"%0*D`^0%ZP*#`% 3`U0"`&-H"L!S973N,@8` M!L,"@S(#Q@<3`H-V,P]_$(1]"H (SPG9._$6?S(U-0* "H$-L0M@X&YG,3 S M%" +"A+R!0P!8P! (%=H>2 022!A;1NP;'=A*GD$(&<2`'0+@&<@&B %H' ( MD 0@;V8@8'1H92!S&\ =L&5^+0# `Q$%H " `9 ",&ST>2X)1: JQE0!9!T!; _'-!#`Y$: M`/H_`0```! ```!-871T M:&5W($9E;&1M86X`0 `',("^LP To: Mark Handley cc: Eric Fleischman , "'confctrl@isi.edu'" , "'rem-conf@es.net'" Subject: Re: In Defense of Interleaved Data Formats In-Reply-To: <8946.857608578@buttle.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 5 Mar 1997, Mark Handley wrote: > >However, there are many occasions when > >"On-Demand Streaming" requires the use of interleaved data formats. > >Here's a few: > > >1. You can save substantial amount of overhead for sessions > >accessed by low speed modems. > ... > >(i.e., on-the-fly compression) to process your "on demand" application > >then the number of sessions you can simultaneously support on that > >server is detrimentally impacted. > > Note that header compression is not end-to-end, but only between your > end-system and its local terminal server. It doesn't impact > multimedia data servers at all. But I assume some form can be implemented here too, if found advantageous? > >2. ... Interleaving encourages tight synchronization and offers a > >higher degree of probability for preserving the designed experience in > >the presence of data loss, network variability, and sunspots. > > Actually this isn't true. Interleaving gives the network less > oportunity to preserve your audio preferentially from your video if > the network gets loaded (which is usually the right thing to do). But gives a tighter synch with less buffering. And eases up the requirements for throttle-back in RTP. It also gives the server a more predictable data stream to work on. > In addition, synchronisation is no easier. You have all the same > information in separate RTP streams that you have in interleaved > streams. In either case you need to cope with mismatches in clock > rate between the video stream and a receiving audio device that which > is not clocked at exactly the frequency the manufacturer claims. Once > you're re-tuning the audio buffering periodically, it makes no > difference whether the streams were transported together or > separately. How about the case when audio arrives slower than the corresponding video? In this case either sizable buffers, fast throttle-back or frame-discarding abilities are required. > >3. On-demand media may be composed of many media types. Some of > >these are "streaming" media types (e.g., voice, video, and MIDI) while > >others are not (e.g., still images, URL flippings, script commands and > >executables). "On demand uses" also encourage the innovative invention > >of rare media types. Regardless, the net effect is that there will be N > >media streams for on-demand usages where N may be quite a handful. > > This seems to be an argument *against* interleaving to me... Hmm. Keep a separate state for each of the streams/connections and you have quite a bit of data. So interleaving might ease up the requirements imposed upon lower protocol layers. How about routing considerations, for example? > >4. Disk-head movement efficiency on the server. The argument here > >is that interleaving encourages more efficient disk storage approaches > >with superior I/O processing capabilities. This directly effects the > >construction of more efficient network streaming approaches. > > Separate streams lets you store your audio and video on different > discs, and hence *improves* performance in some cases :-) But how about the basic case where you do have both the streams originating from the same server? > Besides, if your server isn't doing some form of tuning to available > bandwidth, it's going to be a dinosaur in the long run. Very true. That is a good argument against interleaving. But I'd say at the present BW adaptation isn't the norm. What we need now is efficiency >from simple servers. But in the future multiple independent data streams will probably be the norm. At least if stream aggregation doesn't take place in the lower levels... Sampo Syreeni (Decoy/dAWN), student, From rem-conf-request@es.net Fri Mar 07 16:00:10 1997 Received: from edu.lahti.fi by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Mar 1997 12:59:28 -0800 Received: (qmail 31224 invoked by uid 1067); 7 Mar 1997 21:04:23 -0000 Date: Fri, 7 Mar 1997 23:04:23 +0200 (EET) From: Sampo Syreeni To: Eric Fleischman cc: 'Mark Handley' , "'confctrl@isi.edu'" , "'rem-conf@es.net'" Subject: RE: In Defense of Interleaved Data Formats In-Reply-To: <503A2A3C2932CF118D8800805FD44E1802BBD79F@RED-68-MSG> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 5 Mar 1997, Eric Fleischman wrote: > usage. This requirement is that the "multimedia experience" is preserved > independently of what is happening on the network. Thus, if the network > becomes saturated, the worst thing to do would be to drop a given media > stream in order to preserve another stream based on network assumptions > as to which stream may be "more important" (i.e., your suggestion to > drop video but to preserve audio in a congested situation). Indeed. This brings out the most basic difference between hand-crafted multimedia 'experiences' and the needs of real-time conferencing. The first carries artistic value as a whole, the second is primarily a means of communication. As such, in the first case one needs to preserve the overall experience whereas in the second case getting the message delivered is of prime importance. > "multimedia". While interesting experiences are indeed created using > only those two media types, I would prefer you to think of audio + video > + MIDI + URL flipping + streaming text + active background applications > like stock tickers + still images + .... Why limit ourselves to only > two media types? Certainly the people making streaming "on-demand" > content don't. Because they're the hardest to handle due to their high resource requirements and the relatively high priority they have among our perceptual channels, probably. When you can do both audio and video, you can certainly do the other things you refer to. > sentence. Experience has demonstrated that this observation may very > well be true for segregated media streams, however, it is emphatically > *not* true for interleaved media streams (given a certain preroll > value). But it is true that as long as you have some minimum guarantee of maximum latency between the different data streams, you can buffer multiple streams as well as you can interleaved ones. Sampo Syreeni (Decoy/dAWN), student, From rem-conf-request@es.net Fri Mar 07 16:12:08 1997 Received: from edu.lahti.fi by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Mar 1997 13:11:14 -0800 Received: (qmail 31393 invoked by uid 1067); 7 Mar 1997 21:16:09 -0000 Date: Fri, 7 Mar 1997 23:16:09 +0200 (EET) From: Sampo Syreeni To: Ross Finlayson cc: Eric Fleischman , "'confctrl@isi.edu'" , "'rem-conf@es.net'" Subject: Re: In Defense of Interleaved Data Formats In-Reply-To: <1.5.4.16.19970305223954.0a076550@pop.best.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 5 Mar 1997, Ross Finlayson wrote: > >4. Disk-head movement efficiency on the server. The argument here [snip] > > Incidentally, this confusion - between storage formats and network data > formats - is one that I've seen recently occur in other IETF working groups, > e.g., the "calendar scheduling" group. This is a direct consequence of trying to make things simple: the most basic server conceivable is the one that just spits out the data it has. (Say, HTTP...) > You want it to be possible to implement one of the following end-to-end > semantics when confronted with network loss or delay: > 1/ cancel the presentation > 2/ delay the presentation (as appropriate) 1-2 seem partially equivalent. Just as in the PAUSE issue. > a) Can the particular choice (between 1, 2 and 3) be adequately conveyed - > e.g., in a session description - if different media are *not* interleaved > within network packets. The easiest way to go would be to add a single word (such as those 'encrypted' and other pseudo terms the current draft uses) to indicate the type for each track (session?). > b) Can each of these choices be implemented (efficiently), if different > media are *not* interleaved within network packets. When fighting congestion, one shouldn't assume the client can do anything extra. So it's all about server throttle-back. So these semantics need to conveyed to the server when initiating a stream. This approach isn't dependent on whether the data is interleaved or not. Sampo Syreeni (Decoy/dAWN), student, From rem-conf-request@es.net Fri Mar 07 16:14:26 1997 Received: from buttle.lcs.mit.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Mar 1997 13:13:51 -0800 Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4) id QAA13320; Fri, 7 Mar 1997 16:09:49 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Sampo Syreeni cc: Eric Fleischman , "'rem-conf@es.net'" Subject: Re: In Defense of Interleaved Data Formats In-reply-to: Your message of "Fri, 07 Mar 1997 23:04:23 +0200." Date: Fri, 07 Mar 1997 16:09:49 -0500 Message-ID: <13318.857768989@buttle.lcs.mit.edu> Sender: mjh@buttle.lcs.mit.edu >On Wed, 5 Mar 1997, Eric Fleischman wrote: > >> usage. This requirement is that the "multimedia experience" is preserved >> independently of what is happening on the network. Thus, if the network >> becomes saturated, the worst thing to do would be to drop a given media >> stream in order to preserve another stream based on network assumptions >> as to which stream may be "more important" (i.e., your suggestion to >> drop video but to preserve audio in a congested situation). > >Indeed. This brings out the most basic difference between hand-crafted >multimedia 'experiences' and the needs of real-time conferencing. The >first carries artistic value as a whole, the second is primarily a means >of communication. As such, in the first case one needs to preserve the >overall experience whereas in the second case getting the message >delivered is of prime importance. I believe they're not so different. If you need *no* degradation, you'd better be prepared to reserve network resources, and to pay for them - in this case interleaving gives no advantage over separate streams. If you're not prepared or able to do that, some degree of degradation is very likely, and separate streams at least allow some degree of control over that degradation process - remember packet loss rate does not correspond directly to quality degradation when you compare different media. Separate streams cleanly separate policy for dealing with degradation >from mechanism. Interleaving does not (especially with multicast). Summary: in the best case there's no difference (except for the packet header argument). In typical or worst case, interleaving is a bad idea. Mark From rem-conf-request@es.net Fri Mar 07 17:27:04 1997 Received: from edu.lahti.fi by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Mar 1997 14:26:02 -0800 Received: (qmail 32299 invoked by uid 1067); 7 Mar 1997 22:30:56 -0000 Date: Sat, 8 Mar 1997 00:30:56 +0200 (EET) From: Sampo Syreeni To: Mark Handley cc: Eric Fleischman , "'rem-conf@es.net'" Subject: Re: In Defense of Interleaved Data Formats In-Reply-To: <13318.857768989@buttle.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 7 Mar 1997, Mark Handley wrote: > >> usage. This requirement is that the "multimedia experience" is preserved > >> independently of what is happening on the network. Thus, if the network > >> becomes saturated, the worst thing to do would be to drop a given media > >> stream in order to preserve another stream based on network assumptions > >> as to which stream may be "more important" (i.e., your suggestion to > >> drop video but to preserve audio in a congested situation). > > > >Indeed. This brings out the most basic difference between hand-crafted > >multimedia 'experiences' and the needs of real-time conferencing. The > >first carries artistic value as a whole, the second is primarily a means > >of communication. As such, in the first case one needs to preserve the > >overall experience whereas in the second case getting the message > >delivered is of prime importance. > > I believe they're not so different. If you need *no* degradation, > you'd better be prepared to reserve network resources, and to pay for > them - in this case interleaving gives no advantage over separate > streams. How about when no guaranteed QoS is available (e.g. you're on an Ethernet)? In this case dealing with real-time streams is a pain in the ass. An easy, ready-made presentation would suffice, and therefore interleave is useful. > If you're not prepared or able to do that, some degree of degradation > is very likely, and separate streams at least allow some degree of > control over that degradation process - remember packet loss rate does > not correspond directly to quality degradation when you compare > different media. Indeed. But always having to do multiple streams is a true problem for simple clients. I think I'm taking the position that interlaced data streams as a unit must be supported as much as simple streams do. They truly are the most common ones today. And expect nothing less when digital TV takes on... > Separate streams cleanly separate policy for dealing with degradation > from mechanism. Interleaving does not (especially with multicast). But when multicast isn't available? > Summary: in the best case there's no difference (except for the packet > header argument). In typical or worst case, interleaving is a bad > idea. Explicit interleaving is. But if the original format of the data is interleaved, it would be nice if it could be used as-is as just another stream. Especially since there are interleaved protocols out there. Sampo Syreeni (Decoy/dAWN), student, From rem-conf-request@es.net Fri Mar 07 17:44:44 1997 Received: from buttle.lcs.mit.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Mar 1997 14:41:59 -0800 Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4) id RAA13697; Fri, 7 Mar 1997 17:40:16 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Sampo Syreeni cc: Eric Fleischman , "'rem-conf@es.net'" Subject: Re: In Defense of Interleaved Data Formats In-reply-to: Your message of "Sat, 08 Mar 1997 00:30:56 +0200." Date: Fri, 07 Mar 1997 17:40:16 -0500 Message-ID: <13695.857774416@buttle.lcs.mit.edu> Sender: mjh@buttle.lcs.mit.edu >Indeed. But always having to do multiple streams is a true problem for >simple clients. I think I'm taking the position that interlaced data >streams as a unit must be supported as much as simple streams do. They >truly are the most common ones today. And expect nothing less when digital >TV takes on... No. An interleaved client has to de-interleave the streams and timestamp them, then decode them (different media have different decode delays) then buffer to perform playout adjustment for audio-device clock skew, different decode times, network jitter and audio device buffer latencies, then actually play the media streams out. A non-interleaved client does the same thing, except the streams arrive de-interleaved and pre-timestamped. In either model, you can move the playout buffering around somewhat, but it doesn't change the general principle. Interleaved streams are common because switched circuits are. We don't have that constraint. >But if the original format of the data is >interleaved, it would be nice if it could be used as-is as just another >stream. Especially since there are interleaved protocols out there. Depends if the original format was designed to cope with packet loss. H.221 for example is not, and takes many seconds to recover after a packet loss. It's consituent H.261 and audio codings can however be packetised to cope quite well with loss. Just because your data originated interleaved doesn't mean it's a good idea to transmit it that way. Mark From rem-conf-request@es.net Fri Mar 07 17:53:25 1997 Received: from edu.lahti.fi by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Mar 1997 14:49:36 -0800 Received: (qmail 32454 invoked by uid 1067); 7 Mar 1997 22:54:11 -0000 Date: Sat, 8 Mar 1997 00:54:11 +0200 (EET) From: Sampo Syreeni To: Mark Handley cc: Eric Fleischman , "'rem-conf@es.net'" Subject: Re: In Defense of Interleaved Data Formats In-Reply-To: <13695.857774416@buttle.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 7 Mar 1997, Mark Handley wrote: > >Indeed. But always having to do multiple streams is a true problem for > >simple clients. I think I'm taking the position that interlaced data > >streams as a unit must be supported as much as simple streams do. They > >truly are the most common ones today. And expect nothing less when digital > >TV takes on... > > No. > > An interleaved client has to de-interleave the streams and timestamp > them, then decode them (different media have different decode delays) > then buffer to perform playout adjustment for audio-device clock skew, > different decode times, network jitter and audio device buffer > latencies, then actually play the media streams out. But the code exists. As does the experience. As do ready-made data. > A non-interleaved client does the same thing, except the streams > arrive de-interleaved and pre-timestamped. But you'll have to manage more streams. Handling all the transport protocols isn't very nice. > Interleaved streams are common because switched circuits are. We > don't have that constraint. Assume you own some links and can use policy routing. Then using interlaced data with QoS and your own links will make things a lot easier. With a lot less protocol hassles. > >But if the original format of the data is > >interleaved, it would be nice if it could be used as-is as just another > >stream. Especially since there are interleaved protocols out there. > > Depends if the original format was designed to cope with packet loss. > H.221 for example is not, and takes many seconds to recover after a > packet loss. It's consituent H.261 and audio codings can however be > packetised to cope quite well with loss. Just because your data > originated interleaved doesn't mean it's a good idea to transmit it > that way. I assume we have QoS service. Thus not much packet loss. And on-the-fly conversion isn't going to do good to your servers' performance. Sampo Syreeni (Decoy/dAWN), student, From rem-conf-request@es.net Sun Mar 09 04:47:14 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Sun, 9 Mar 1997 01:45:04 -0800 Received: from port4.precept.com by precept.com (SMI-8.6/SMI-SVR4) id BAA12718; Sun, 9 Mar 1997 01:37:19 -0800 Date: Sun, 9 Mar 1997 01:44:00 -0800 (PST) From: Stephen Casner To: "M. Reha Civanlar" cc: rem-conf@es.net Subject: Re: Problems with RTP Payload Types In-Reply-To: <330E1103.2D28@research.att.com> Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 21 Feb 1997, M. Reha Civanlar wrote: > I guess, one remaining question is how will one define new RTP payloads > (not PT assignments) for these new codecs so that they can be archived > as IETF documents. Is it viable that the AVT group continues to monitor > this process for the foreseeable future? > > Stephen Casner wrote: > > > > Regarding the non-dynamic part of the space, it seems likely that many > > new codecs will be used only with dynamic payload types throughout > > their lifetime. Perhaps only (a subset of) those standardized by the > > ITU will get static PT assignments. It may be sufficient for payload format specifications to be posted as Internet Drafts and reviewed via email to the rem-conf and/or ietf mailing lists without requiring a face-to-face AVT meeting. There are plenty of other examples, such as MIME type definitions, which are managed by the IANA and RFC Editor processes subsequent to the completion of the main MIME working group. There could well be a very specific, short-term working group formed to handle some future payload format specification if it were complex enough to warrant that. -- Steve From rem-conf-request@es.net Sun Mar 09 04:49:33 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Sun, 9 Mar 1997 01:48:31 -0800 Received: from port4.precept.com by precept.com (SMI-8.6/SMI-SVR4) id BAA12715; Sun, 9 Mar 1997 01:25:39 -0800 Date: Sun, 9 Mar 1997 01:32:20 -0800 (PST) From: Stephen Casner To: Bernard Aboba cc: "rem-conf@es.net" Subject: Re: Profiles In-Reply-To: <01BC25AA.1CAE8A40@multi> Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Bernard, > OK, I'll bite. The profile I would like to see would be: Thanks for responding to my request for proposals. > A profile that brings the bandwidth fraction down below 5 percent. > To prevent this from being used for abusive purposes, it could be > interpretted as a fraction of 5 percent. That way, you could specify > a bandwidth fraction of less than 5 percent, but never more. > > Setting the fraction to zero would be equivalent to turning off > RTCP entirely. Where would the bandwidth fraction be specified? I have suggested an alternate profile that specified no sending of RTCP, to be indicated in SDP files by something like "RTP/AVU" (for unidirectional) where now there is only one choice "RTP/AVP". There could be more to indicate other fractions, but this would likely be unwieldy. Note that it is important for all participants to know what the fraction is and use the same value as explained in section 6.2.1 or thereabouts. If it were a parameter communicated in RTCP, say by "the" sender, this could be a problem on startup. > While we talked about a number of other possibilities at the AVT > meeting, in thinking more about them, I'm either convinced that > they don't help (putting RTCP on a separate group), or could > be abused too easily (sending RTCP to a unicast address). I agree that there were at least considerations requiring caution with all of the ideas we discussed at the AVT meeting. -- Steve From rem-conf-request@es.net Sun Mar 09 05:15:59 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Sun, 9 Mar 1997 02:15:04 -0800 Received: from port4.precept.com by precept.com (SMI-8.6/SMI-SVR4) id BAA12732; Sun, 9 Mar 1997 01:48:28 -0800 Date: Sun, 9 Mar 1997 01:55:20 -0800 (PST) From: Stephen Casner To: rem-conf@es.net Subject: AVT Meeting in Memphis Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In case you were curious, the Audio/Video Transport working group will meet at the Memphis IETF. AVT is not shown on the draft agenda because the schedule for working groups in the Transport Area is established separately as a "track" by the Area Directors. Those WGs are added to the agenda whenn the track schedule is completed. I have requested two slots again since we have never failed to use all the allotted time and even a few extra minutes. I hereby solicit requests for agenda slots. I will be out this next week, but will work on organizing the meeting agenda with your input when I return. -- Steve From rem-conf-request@es.net Mon Mar 10 08:19:46 1997 Received: from mail.storm.ca by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Mar 1997 05:18:55 -0800 Received: from default (storm01p15.storm.ca [24.112.15.240]) by mail.storm.ca (8.8.0/8.7.3) with SMTP id IAA09772 for ; Mon, 10 Mar 1997 08:18:49 -0500 (EST) Message-Id: <199703101318.IAA09772@mail.storm.ca> Comments: Authenticated sender is From: Chris Brown To: Video Date: Sun, 9 Mar 1997 08:10:55 -0500 Subject: Asking Advice on MPEG/MJPEG Reply-to: chris@storm.ca Priority: normal X-Tagname: PM-MERGE X-mailer: Pegasus Mail for Win32 (v2.52) Would you be able to make any suggestions about the relative merits of M-JPEG or MPEG, for either production or distribution of video? Chris Brown chris@storm.ca http://www.storm.ca/~chris From rem-conf-request@es.net Mon Mar 10 15:20:26 1997 Received: from buttle.lcs.mit.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Mar 1997 12:19:47 -0800 Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4) id PAA16026; Mon, 10 Mar 1997 15:18:06 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: chris@storm.ca cc: Video Subject: Re: Asking Advice on MPEG/MJPEG In-reply-to: Your message of "Sun, 09 Mar 1997 08:10:55 EST." <199703101318.IAA09772@mail.storm.ca> Date: Mon, 10 Mar 1997 15:18:06 -0500 Message-ID: <16024.858025086@buttle.lcs.mit.edu> Sender: mjh@buttle.lcs.mit.edu >Would you be able to make any suggestions about the relative >merits of M-JPEG or MPEG, for either production or distribution >of video? I don't know about production, but for distribution it's a trade-off (isn't everything!). Both are DCT based, but M-JPEG compresses every frame completely independently (intra-frame compression), and sends every block of pixels in every frame. This means it's high bandwidth, but resilient to packet loss as damage is repaired by the next frame. MPEG can use various levels of inter-frame compression (only coding differences between frames). This makes it considerably lower bandwidth than M-JPEG for the same quality, but damage caused by packet loss will propogate from frame to frame, and generally cause much more visible artifacts. H.261 is pretty similar to MPEG in how it performs its compression. For typical internet use, what Steve McCanne did in vic was what they call "robust H.261", where only intra-frame compression is performed, but only those blocks that change more than some threshold are actually sent. This is a good point in the bandwidth/resilience spectrum. Whether you can get such a mode out of an off-the-shelf MPEG encoder I do not know. Mark From rem-conf-request@es.net Mon Mar 10 17:31:40 1997 Received: from monet.caad.ed.ac.uk by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Mar 1997 14:30:39 -0800 Received: from [129.215.100.202] (mac-202.caad.ed.ac.uk [129.215.100.202]) by monet.caad.ed.ac.uk (8.6.13/8.6.9) with SMTP id WAA02238; Mon, 10 Mar 1997 22:31:39 GMT Date: Mon, 10 Mar 1997 22:31:39 GMT Message-Id: <199703102231.WAA02238@monet.caad.ed.ac.uk> X-Sender: richard@monet.caad.ed.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: performance@haven.epm.ornl.gov, Peter.Thomas@csm.uwe.ac.uk, pnr12@hermes.cam.ac.uk, prevot@ifhpserv.insa-lyon.fr, r.b.yunus@sheffield.ac.uk (R Mohd Yunus), R.Beheshti@CT.TUDelft.nl, R.conroy@ucl.ac.uk, r.m.oxman@bwk.tue.nl, RAFAEL822@HOTMAIL.COM ( GENARO R. URUETA), rafaelp@cogs.susx.ac.uk, ram@dcs.ed.ac.uk, randeva@pwgsc.gc.ca (A Randev), regli@cme.nist.gov, rem-conf@es.net, reres@laas.fr, rgarcia@zeus.dci.ubiobio.cl, richard@caad.ed.ac.uk, ROBIN@gsaup.ucla.edu, robt@gomark.com, roseann@acc.rwu.edu, rothenbu@irit.fr, rothenbu@irit.fr, rschultz@informatik.uni-rostock.de, rsj4318@pro.via-rs.com.br, rsj4318@pro.via-rs.com.br, ann@vortex.ufrgs.br (A.M. BUSKO) From: Richard.Coyne@ed.ac.uk (Richard Coyne) Subject: EuropIA'97 registration Cc: Ronnie.Galloway@ed.ac.uk, mike@caad.ed.ac.uk If you are intending to register for EuropIA'97, and have not done so, then please do so urgently, and email your intention to Ronnie.Galloway@ed.ac.uk Authors 175 pounds stirling Non-authors 250 pounds stirling Conference Dinner 27 pounds stirling EuropIA'97 Design and the Net 2-3 April 1997 Registrations: Ronnie.Galloway@ed.ac.uk http://www.caad.ed.ac.uk/europia UnivEd Technologies Limited 11 South College Street, Edinburgh, EH8 9AA Ph +44 131 650 9020 Fax +44 131 650 9019 --------------------------------------------------------------------------- Richard Coyne Tel: +44 131 650 2332 Department of Architecture Fax: +44 131 650 8019 University of Edinburgh email: Richard.Coyne@ed.ac.uk 20 Chambers Street EH1 1JZ Scotland http://www.caad.ed.ac.uk/~richard/ From rem-conf-request@es.net Mon Mar 10 17:44:08 1997 Received: from zephyr.isi.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Mar 1997 14:43:19 -0800 Received: from can.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Mon, 10 Mar 1997 14:43:16 -0800 Date: Mon, 10 Mar 97 14:44:41 PST From: braden@isi.edu Posted-Date: Mon, 10 Mar 97 14:44:41 PST Message-Id: <9703102244.AA01447@can.isi.edu> Received: by can.isi.edu (4.1/4.0.3-6) id ; Mon, 10 Mar 97 14:44:41 PST To: decoy@edu.lahti.fi, mjh@isi.edu Subject: Re: In Defense of Interleaved Data Formats Cc: ericfl@microsoft.com, rem-conf@es.net *> *> I believe they're not so different. If you need *no* degradation, *> you'd better be prepared to reserve network resources, and to pay for *> them Yes! yes! Bob Braden From rem-conf-request@es.net Mon Mar 10 22:10:41 1997 Received: from piraya.electrum.kth.se by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Mar 1997 19:09:55 -0800 Received: from drum.it.kth.se (drum.it.kth.se [130.237.213.23]) by piraya.electrum.kth.se (8.7.3/8.7.3) with ESMTP id EAA12325; Tue, 11 Mar 1997 04:09:43 +0100 (MET) Message-Id: <199703110309.EAA12325@piraya.electrum.kth.se> To: mjh@isi.edu Cc: chris@storm.ca, rem-conf@es.net From: Magnus Danielson Subject: Re: Asking Advice on MPEG/MJPEG In-Reply-To: Your message of "Mon, 10 Mar 1997 15:18:06 -0500" References: <16024.858025086@buttle.lcs.mit.edu> X-Mailer: Mew version 1.06 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 11 Mar 1997 04:09:42 +0100 Sender: e93_mda@drum.it.kth.se >>>>> "MH" == Mark Handley writes: >> Would you be able to make any suggestions about the relative >> merits of M-JPEG or MPEG, for either production or distribution >> of video? MH> I don't know about production, but for distribution it's a trade-off MH> (isn't everything!). MH> Both are DCT based, but M-JPEG compresses every frame completely MH> independently (intra-frame compression), and sends every block of MH> pixels in every frame. This means it's high bandwidth, but resilient MH> to packet loss as damage is repaired by the next frame. JPEG and especially M-JPEG is much more interesting for packet based transmissions or other environments with relatively high loss/corruption of data. The M-JPEG is a specific part of the JPEG standard in which you can avoid sending some headers and tables (quantization and huffman tables) for each picture, nothing really revolutionary. The current MPEG standards will not survive these environments of hi loss very well, since the I frames (which holds the most quantity information) is also most likely to be hit by loss, partly since they are so large part of a transmission (relative the size of a P or B frame) but also since it will cause an burst of packets when sent, and this tends to fill buffers... and retransmissions is usually out of question... MPEG is however well suited for lowloss environments where you migth get better quality out of the same (fixed) bandwidth. If you go for a good quality of the shelf encoder/decoder box you migth get really good quality over a considerable lower bandwidth than raw video. MPEG is now being used in everday commercial TV transmission links. However, this is normally not recieved as MPEG in the end. MH> MPEG can use various levels of inter-frame compression (only coding MH> differences between frames). This makes it considerably lower MH> bandwidth than M-JPEG for the same quality, but damage caused by MH> packet loss will propogate from frame to frame, and generally cause MH> much more visible artifacts. True. Also, there is many more parameters to tweak in MPEG to balance the quality in the encoder. Propper setting of these is necessary if you are at the bandwidth borders... MH> H.261 is pretty similar to MPEG in how it performs its compression. MH> For typical internet use, what Steve McCanne did in vic was what they MH> call "robust H.261", where only intra-frame compression is performed, MH> but only those blocks that change more than some threshold are MH> actually sent. This is a good point in the bandwidth/resilience MH> spectrum. Whether you can get such a mode out of an off-the-shelf MH> MPEG encoder I do not know. The H.261 is much more restricted than the original MPEG 1 standard, but is very usefull in the lower bandwidth ranges (it is originally specified for up to 1920 kbps lines over primary rate ISDN type of lines). The H.261 is so similar and the standard is so short, that you can start of reading that H.261 spec and the walk over to the MPEG 1 standard. One thing to keep in mind is that these schemes also have various needs for CPU power and can also cause diffrent propagation delays. Some of these things have to be kept in mind. In both MPEG and H.261 you can run motion estimation and this is a *very* expensive operation, there is smart approximations which gives a really decent picture for much less CPU, but those have to be exploited or you have to pay for the extra processing need. Also, just simple prediction (no motion estimation) will cause an extra processing need. In MPEG and H.261 will I and P frames have about the same propagation delay effect, but as soon as you get the B frames in there you will need to delay frames so that the necessary reordering can be done since in B frames is the prediction done both forward and backward in time... since we can't use data that will come we need to delay the signal so that the data is there before it is needed. The extra propagation delay is normally quite OK in CD-ROM and TV link cases but is certainly something unwanted in interactive situations. So, there is no system which solves all problems... you have to look at the specific problem in order to say what to do and what to use. Regards, Magnus From rem-conf-request@es.net Tue Mar 11 06:22:32 1997 Received: from x4u2.desy.de by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Mar 1997 03:21:45 -0800 Received: (from bobyshev@localhost) by x4u2.desy.de (8.6.10/8.6.9) id LAA05921; Tue, 11 Mar 1997 11:21:36 GMT Date: Tue, 11 Mar 1997 12:21:36 +0100 (MET) From: Andrey Bobyshev To: rem-conf@es.net Subject: MBONE Announcement of CHEP97 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII DESY is pleased to announce the MBONE broadcast ------------------------------------------------- of CHEP'97 Plenary meetings from Berlin on April 7-11,1997. ---------------------------------------------------------- Date: 7-11 April, 1997 Time: 9:00 - 18:00 MET To get more information about CHEP97 conference program, please look at URL http://www.desy.de/chep97. The MBONE broadcast is announced via SDR tool as "CHEP'97 - Plenary Sessions from Berlin, Germany". For audio transmission we are going to use fphone 3.xx which is free of charge. Release 3.xx implements a new redundency scheme, which is not compatible with previous ones. So you may want to download the latest version of fphone. Please find more information about fphone at URL http://www.inria.fr/rodeo/fphone . In case of problems or questions please send a message to mbone@desy.de Best regards, NOC of DESY. From rem-conf-request@es.net Tue Mar 11 09:04:20 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Mar 1997 06:03:13 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id GAA10367 for ; Tue, 11 Mar 1997 06:03:20 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma010362; Tue Mar 11 06:02:41 1997 Received: by hille.msri.org (8.7/MSRI) id GAA11991; Tue, 11 Mar 1997 06:02:27 -0800 (PST) Date: Tue, 11 Mar 1997 06:02:27 -0800 (PST) Message-Id: <199703111402.GAA11991@hille.msri.org> To: rem-conf@es.net From: m1 Reply-to: m1@msri.org Subject: Donald Knuth "Graph Drawing from a User's Perspective" MBone Broadcast Announcement ---------------------------- Title: Donald Knuth "Graph Drawing from a User's Perspective" Date: Mar 18, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/lecturenotes/96/knuth/ Description: Donald Knuth's 9/18/96 from Graph Drawing 96 at MSRI. No abstract nor slides available. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Mar 11 09:06:18 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Mar 1997 06:05:07 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id GAA10401 for ; Tue, 11 Mar 1997 06:05:21 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma010393; Tue Mar 11 06:04:30 1997 Received: by hille.msri.org (8.7/MSRI) id GAA12025; Tue, 11 Mar 1997 06:04:17 -0800 (PST) Date: Tue, 11 Mar 1997 06:04:17 -0800 (PST) Message-Id: <199703111404.GAA12025@hille.msri.org> To: rem-conf@es.net From: m1 Reply-to: m1@msri.org Subject: Donald Knuth "Some Research Problems for Combinatorialists" MBone Broadcast Announcement ---------------------------- Title: Donald Knuth "Some Research Problems for Combinatorialists" Date: Mar 19, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/lecturenotes/97/knuth/ Description: Donald Knuth's 1/27/97 talk in the MSRI Combinatorics seminar. No abstract nor slides available. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Mar 11 09:09:41 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Mar 1997 06:08:14 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id GAA10437 for ; Tue, 11 Mar 1997 06:08:21 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma010431; Tue Mar 11 06:07:30 1997 Received: by hille.msri.org (8.7/MSRI) id GAA12060; Tue, 11 Mar 1997 06:07:16 -0800 (PST) Date: Tue, 11 Mar 1997 06:07:16 -0800 (PST) Message-Id: <199703111407.GAA12060@hille.msri.org> To: rem-conf@es.net From: m1 Reply-to: m1@msri.org Subject: John Conway "Knotation" MBone Broadcast Announcement ---------------------------- Title: John Conway "Knotation" Date: Mar 20, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/lecturenotes/97/knuth/ Description: John Conway's 3/10/97 talk at the MSRI Computational and Algorithmic Methods in 3-Dimensional Topology workshop. How can we choose names for simple knots so that we can always rebuild a knot from its name, and yet so that it will usually be easy to find the name from any form of the knot? I shall describe a simple arithmetical notation that accomplishes this for a large class of knots. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Mar 11 12:43:37 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Mar 1997 09:42:07 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id JAA12681 for ; Tue, 11 Mar 1997 09:42:21 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma012672; Tue Mar 11 09:42:06 1997 Received: by hille.msri.org (8.7/MSRI) id JAA12213; Tue, 11 Mar 1997 09:41:52 -0800 (PST) Date: Tue, 11 Mar 1997 09:41:52 -0800 (PST) Message-Id: <199703111741.JAA12213@hille.msri.org> To: rem-conf@es.net From: gruen Reply-to: gruen@rvs.uni-hannover.de Subject: DFN/DANTE/SWICH/RVS CeBIT 97 Test MBone Broadcast Announcement ---------------------------- Title: DFN/DANTE/SWICH/RVS CeBIT 97 Test Date: Mar 12, 1997 Time: 15:00 MET 2 hours Contact: gruen@rvs.uni-hannover.de URL: http://www.rvs.uni-hannover.de/people/gruen/cebit97-broadcasts.html Description: During the CeBIT 97 there will be several MBone broadcast with different scopes from the booth "Treffpunkt 22". This session is used to check the connectivity. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Mar 11 12:46:07 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Mar 1997 09:45:07 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id JAA12719 for ; Tue, 11 Mar 1997 09:45:22 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma012716; Tue Mar 11 09:45:18 1997 Received: by hille.msri.org (8.7/MSRI) id JAA12244; Tue, 11 Mar 1997 09:45:05 -0800 (PST) Date: Tue, 11 Mar 1997 09:45:05 -0800 (PST) Message-Id: <199703111745.JAA12244@hille.msri.org> To: rem-conf@es.net From: gruen Reply-to: gruen@rvs.uni-hannover.de Subject: DFN/DANTE/SWICH RVS CeBIT 97 Broadcast Test MBone Broadcast Announcement ---------------------------- Title: DFN/DANTE/SWICH RVS CeBIT 97 Broadcast Test Date: Mar 12, 1997 Time: 18:00 MET 3 hours Contact: gruen@rvs.uni-hannover.de URL: http://www.rvs.uni-hannover.de/people/gruen/cebit97-broadcasts.html Description: During the CeBIT 97 there will be several MBone broadcast with different scopes from the booth "Treffpunkt 22". This session is used to check the connectivity. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Mar 11 12:48:46 1997 Received: from ntigate.rich.nt.com (actually ntigate.nt.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Mar 1997 09:47:27 -0800 Received: from nrtpm9c1.rtp.nt.com by ntigate.rich.nt.com with SMTP (PP); Tue, 11 Mar 1997 17:46:21 +0000 Received: from nrtpddd3.rtp.nt.com by nrtpm9c1.rtp.nt.com with SMTP (1.38.193.4/16.2) id AA23752; Tue, 11 Mar 97 12:43:14 -0500 Received: by nrtpddd3.rtp.nt.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC2E10.4C7B3A70@nrtpddd3.rtp.nt.com>; Tue, 11 Mar 1997 11:35:19 -0500 Message-Id: From: "Tallant, David (D.L.)" To: "'rem-conf@es.net'" Subject: subscribe Date: Tue, 11 Mar 1997 11:35:26 -0500 Return-Receipt-To: "Tallant, David (D.L.)" X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Mime-Version: 1.0 From rem-conf-request@es.net Tue Mar 11 13:05:22 1997 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Mar 1997 10:03:06 -0800 Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id KAA14202 for ; Tue, 11 Mar 1997 10:02:50 -0800 (PST) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.6/8.7.3) id KAA25546 for rem-conf@es.net; Tue, 11 Mar 1997 10:02:59 -0800 (PST) Original-Received: by ccm.hf.intel.com (ccmgate 3.2 #7) Tue, 11 Mar 97 10:02:58 PST PP-warning: Illegal Received field on preceding line Date: Tue, 11 Mar 97 10:01:00 PST From: Christian Maciocco Message-ID: To: rem-conf@es.net Subject: Re[2]: Profiles >Note that it is important for all participants to know what the >fraction is and use the same value as explained in section 6.2.1 or >thereabouts. If it were a parameter communicated in RTCP, say by >"the" sender, this could be a problem on startup. As stated in the RFC, "The control traffic should be limited to a small and known fraction of the session bandwidth,...". This might be a problem for adaptive applications which could start their sessions in the 64 Kb/s range and reach 3 Mb/s or higher on an Intranet when there is no congestion. I'd like the RTCP bandwidth to get its share of the new session's bandwidth. Maybe the senders could advertise their new session's bandwidth through an RTCP message when they go over a threshold, e.g. an order of magnitude over what has been advertised for the session, so all receivers use now a new constant. If multiple senders have reached the threshold they'll learn through RTCP that the bandwidth has already been advertized. Christian From rem-conf-request@es.net Tue Mar 11 14:01:54 1997 Received: from nobozo.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Mar 1997 11:00:51 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id LAA00096 for ; Tue, 11 Mar 1997 11:00:40 -0800 Date: Tue, 11 Mar 1997 11:00:40 -0800 Message-Id: <199703111900.LAA00096@nobozo.CS.Berkeley.EDU> X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: Jerrlyn Iwata Subject: [Reminder] Berkeley Multimedia & Graphics Seminar Berkeley Multimedia and Graphics Seminar (Wednesday March 12, 1997 12:30-2:00 PDT 405 Soda Hall) "Interactive Commerce: Technology Solutions for Business on the Web" Pia Chamberlain Connect, Inc. MBONE BROADCAST BEGINS AT 12.40 PDT (GMT - 8 HOURS) From rem-conf-request@es.net Tue Mar 11 15:06:27 1997 Received: from relay.hq.tis.com by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Mar 1997 12:02:53 -0800 Received: by relay.hq.tis.com; id PAA23787; Tue, 11 Mar 1997 15:01:01 -0500 (EST) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (3.2) id xma023779; Tue, 11 Mar 97 15:00:31 -0500 Received: from clipper (localhost [127.0.0.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with ESMTP id OAA07014; Tue, 11 Mar 1997 14:58:47 -0500 (EST) Message-Id: <199703111958.OAA07014@clipper.hq.tis.com> To: Jon Crowcroft cc: rem-conf@es.net, kelly@tis.com, sterne@tis.com Subject: Re: socks/mbone firewalls In-reply-to: Your message of "Wed, 05 Mar 1997 17:47:26 GMT." <2466.857584046@cs.ucl.ac.uk> Date: Tue, 11 Mar 1997 14:58:46 -0500 From: Kelly Djahandari >in order to help some commercial intranet and ISP company managers >feel happier about mbone deployment: > >can anyone point me at a discussion paper/description of firewall >usage, multicast UDP and mbone applications, and any rationale as to >a) attacks (e.g. denial of service esp., but usual service breakins >and disclosure etc obviously useful too) >b) defenses >c) procedures for mbone app<->firewall auth > >etc etc > >thanks >jon Jon, We've written a paper describing work we did developing an MBone proxy for the TIS Internet Firewall Toolkit. It has some discussion of security issues and the approach we took to reducing risk when bringing multicast UDP datagrams into a firewall protected enclave, without modifying MBone applications. The paper is on our web site at http://www.tis.com/docs/research/network/mbone/mboneabs.html . Hope it helps, Kelly From rem-conf-request@es.net Tue Mar 11 15:34:22 1997 Received: from cs.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Mar 1997 12:33:24 -0800 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id PAA19943; Tue, 11 Mar 1997 15:33:18 -0500 (EST) Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id PAA02728; Tue, 11 Mar 1997 15:33:17 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <3325C18C.A0C@cs.columbia.edu> Date: Tue, 11 Mar 1997 15:33:16 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Christian Maciocco CC: rem-conf@es.net Subject: Re: Profiles References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Since senders get to send more frequently than receivers and thus are likely to be heard from reasonably often even in large groups, receivers could simply base their session bandwidth estimate on the sender reports. If packet loss is ignored, receivers could also monitor the actual data bandwidth coming in, suitably smoothed. (This tends to cause problems with on-off sources like voice, however.) SRs have the problem that the rate during the last interval where a source was sending doesn't get cleared (since the sender that stopped sending won't be sending another SR). It also allows buggy or malicious implementations to lie about the sending rate and cause everyone to send too many RTCP packets. Henning From rem-conf-request@es.net Wed Mar 12 01:48:12 1997 Received: from apollo.pc-comp-sol.ca (actually 207.6.6.3) by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Mar 1997 22:47:34 -0800 Received: from [207.6.6.201] by apollo.pc-comp-sol.ca (NTMail 3.01.03) id fa005933; Wed, 12 Mar 1997 01:46:49 -0500 Message-ID: <33267B9D.7582@pc-comp-sol.ca> Date: Wed, 12 Mar 1997 01:47:09 -0800 From: tsyed X-Mailer: Mozilla 3.0Gold (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.pc-comp-sol.ca Hi I am doing my Masters in Multimedia. I am looking an RTP kit on Window NT environment for my University Lab. Is there any free or cheap RTP Kit available which I can used for my project? Thanks Tariq A syed From rem-conf-request@es.net Wed Mar 12 14:18:44 1997 Received: from ns.research.att.com by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Mar 1997 11:18:05 -0800 Received: from research.att.com ([135.205.32.20]) by ns; Wed Mar 12 14:17:04 EST 1997 Received: from surfcity.research.att.com ([135.16.210.211]) by research; Wed Mar 12 14:15:43 EST 1997 Received: from pcmrc.research.att.com (pcmrc [135.16.211.43]) by surfcity.research.att.com (8.8.4/8.7.3) with SMTP id OAA02244 for ; Wed, 12 Mar 1997 14:10:50 -0500 (EST) Message-ID: <3326FFF9.3CD0@research.att.com> Date: Wed, 12 Mar 1997 14:11:53 -0500 From: "M. Reha Civanlar" Reply-To: civanlar@research.att.com Organization: AT&T Labs - Research X-Mailer: Mozilla 3.0Gold (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: Re: Asking Advice on MPEG/MJPEG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I would like to add a few good words for MPEG to MJPEG/MPEG discussions posted before :-) Mark Handley wrote: > MPEG can use various levels of inter-frame compression (only coding > differences between frames). This makes it considerably lower > bandwidth than M-JPEG for the same quality, but damage caused by > packet loss will propogate from frame to frame, and generally cause > much more visible artifacts. > Some other advantages of MPEG for transmission include: 1. MQUANT: it is possible to change the quantization factor at the macroblock level. This way bits can be deployed where they are needed the most. So, an all intra MPEG (all I frames) can be more efficient than MJPEG. 2. Slices: Slices have self identifying start codes and can be used to partition a picture to decodable parts. Although, some JPEG extensions include similar mechanisms, I have not seen their implementations yet. All MPEG encoders, however, can implement the above functionality. > H.261 is pretty similar to MPEG in how it performs its compression. > For typical internet use, what Steve McCanne did in vic was what they > call "robust H.261", where only intra-frame compression is performed, > but only those blocks that change more than some threshold are > actually sent. This is a good point in the bandwidth/resilience > spectrum. Whether you can get such a mode out of an off-the-shelf > MPEG encoder I do not know. > A mode close to this may be achieved by restricting the motion estimation range to zero and using P frames, both of which are possible in almost all off-the-shelf MPEG encoders. Magnus Danielson wrote: > The current MPEG standards will not survive these environments of hi > loss very well, since the I frames (which holds the most quantity > information) is also most likely to be hit by loss, partly since they > are so large part of a transmission (relative the size of a P or B > frame) but also since it will cause an burst of packets when sent, and > this tends to fill buffers... and retransmissions is usually out of > question... To fight with this problem, current MPEG-2 standard do allow using I-slices (e.g., a bundle of 16 lines that are intra coded) in inter coded pictures instead of using I frames. -- M. Reha Civanlar Principal Technical Staff Member, AT&T Labs - Research 101 Crawfords Corner Road, 4C520, Holmdel, NJ 07733-3030 (908) 949 6705 (908) 949 3697 (fax) civanlar@research.att.com http://www.research.att.com/info/mrc From rem-conf-request@es.net Wed Mar 12 14:58:51 1997 Received: from dogbert.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Mar 1997 11:58:05 -0800 Received: from dogbert.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by dogbert.CS.Berkeley.EDU (8.8.4/8.6.9) with ESMTP id LAA18112; Wed, 12 Mar 1997 11:51:52 -0800 (PST) Message-Id: <199703121951.LAA18112@dogbert.CS.Berkeley.EDU> X-Mailer: exmh version 1.6.9 8/22/96 To: rem-conf@es.net, 298@dogbert.CS.Berkeley.EDU Subject: UCB Seminar Announcement From: David Simpson X-url: http://www-plateau.cs.berkeley.edu/people/davesimp/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Mar 1997 11:51:51 -0800 Sender: davesimp@plateau.CS.Berkeley.EDU Due to problems that that I am still trying to track down, SAP announcements do not appear to be leaving our local UCB MBone cloud. The seminar is still on today at the following addresses: audio: 224.2.242.81/25378 video: 224.2.178.217/49780 wb: 224.2.167.198/46760 Sorry for the inconvience... Here is the sdp file: n=2149589067 2149589067 858195530 224.2.127.254 9875 127 trusted v=0 o=davesimp 3067184308 3067184330 IN IP4 128.32.32.75 s=UCB Multimedia Seminar i=UC Berkeley Multimedia Seminar. This week's speaker is Pia Chamberlain from Connect, Inc., on ``Interactive Commerce: Technology Solutions for Business on the Web.'' u=http://bmrc.berkeley.edu/298/ e=David Simpson p=David Simpson +1-510-643-7106 c=IN IP4 224.2.242.81/127 t=3067187400 3069613800 r=604800 7200 0 a=tool:sdr v2.3a1 a=type:broadcast m=audio 25378 RTP/AVP 0 c=IN IP4 224.2.242.81/127 a=ptime:40 m=video 49780 RTP/AVP 31 c=IN IP4 224.2.178.217/127 m=whiteboard 46760 udp wb c=IN IP4 224.2.167.198/127 -- ---------------------------------------------------------------------------- David Simpson, davesimp@cs.berkeley.edu Graduate Student - Computer Science - UC Berkeley http://www.cs.berkeley.edu/~davesimp From rem-conf-request@es.net Wed Mar 12 17:28:13 1997 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Mar 1997 09:55:01 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 12 Mar 1997 17:54:12 +0000 To: Kelly Djahandari cc: rem-conf@es.net, sterne@tis.com Subject: Re: socks/mbone firewalls In-reply-to: Your message of "Tue, 11 Mar 1997 14:58:46 EST." <199703111958.OAA07014@clipper.hq.tis.com> Date: Wed, 12 Mar 1997 17:54:11 +0000 Message-ID: <2546.858189251@cs.ucl.ac.uk> From: Jon Crowcroft >We've written a paper describing work we did developing an MBone >proxy for the TIS Internet Firewall Toolkit. It has some discussion of >security issues and the approach we took to reducing risk when bringing >multicast UDP datagrams into a firewall protected enclave, without >modifying MBone applications. The paper is on our web site at >http://www.tis.com/docs/research/network/mbone/mboneabs.html . Kelly ok - this is nice (at least its a good start!!) 2 problems 1/ you match multicast to unicast - you reasons are good, but many intranets have better multicast than the internet at large, and it seems a pitty not to map outside multicast to inside multicast, maybe on "well known safe ports" and "different addresses" 2/ my program could do that:-) 3/ you could do this with secure sessions 4/ you could use SDR and SIP as tools to initiate the firewall access, and setup a relay between the outside generalied port, and the inside one (maybe, as i say on a different mcast addr/port pair for safety...) - this would be neat, but might not fit quickly with audited code...as per your toolkit and socks and so on....but its UDP, so its a lot easier to think through and check than TCP (imho:-) cheers jon From rem-conf-request@es.net Thu Mar 13 14:51:29 1997 Received: from nobozo.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Mar 1997 11:50:38 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id LAA21859 for ; Thu, 13 Mar 1997 11:50:37 -0800 Date: Thu, 13 Mar 1997 11:50:37 -0800 Message-Id: <199703131950.LAA21859@nobozo.CS.Berkeley.EDU> X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: Jerrlyn Iwata Subject: Berkeley Multimedia & Graphics Seminar > > Berkeley Multimedia and Graphics Seminar > (Wednesday March 19, 1997 12:30-2:00 PDT 405 Soda Hall) > > "The Prince and the Pauper, or, is content really King?" > > John Taysom > Reuters, Ltd. > > > >John Taysom, SVP with Reuters based in Palo Alto, will talk about business models available to content providers on the Internet. Reuters is a supplier of news to most prominent web sites and an investor in Yahoo, Infoseek and Sportsline as well as several Internet infrastructure companies. > >Reuters is a 150 year old news agency. Reuters operates one of the largest private networks in the world providing real-time news, trading data and transactional systems for the banking sector delivered over approximately 300,000 Pcs. This is in addition to being the premier world news agency for text, photographs and video news. Reuters has been experimenting with the public Internet as a distribution system for the last three years. > >John Taysom has worked for Reuters for 13 years, living and working in the Far East, the Middle East, Europe and now the U.S.A. John runs a corporate venture fund for Reuters investing in companies whose technology or content Reuters wishes to use or market internationally. > >------------------------------------------------------------------------------ >This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40 PDT (GMT - 8 hrs). See sdr or http://bmrc.berkeley.edu/298 for instructions on setting up, connecting to, and operating the MBONE tools. > >Please direct all technical questions to davesimp@cs.berkeley.edu > > From rem-conf-request@es.net Fri Mar 14 12:57:05 1997 Received: from relay.hq.tis.com by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Mar 1997 09:56:19 -0800 Received: by relay.hq.tis.com; id MAA21814; Fri, 14 Mar 1997 12:54:14 -0500 (EST) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (3.2) id xma021769; Fri, 14 Mar 97 12:53:48 -0500 Received: from clipper (localhost [127.0.0.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with ESMTP id MAA25187; Fri, 14 Mar 1997 12:52:11 -0500 (EST) Message-Id: <199703141752.MAA25187@clipper.hq.tis.com> To: Jon Crowcroft cc: Kelly Djahandari , rem-conf@es.net, sterne@tis.com Subject: Re: socks/mbone firewalls In-reply-to: Your message of "Wed, 12 Mar 1997 17:54:11 GMT." <2546.858189251@cs.ucl.ac.uk> Date: Fri, 14 Mar 1997 12:52:10 -0500 From: Kelly Djahandari Jon, >ok - this is nice (at least its a good start!!) > >2 problems >1/ you match multicast to unicast - you reasons are good, but many >intranets have better multicast than the internet at large, and it >seems a pitty not to map outside multicast to inside multicast, maybe >on "well known safe ports" and "different addresses" Yes - we discuss that as useful extension in the Control vs. Performance section. >2/ my program could do that:-) Yes - we cite your monstermash program in the Related Work section. >3/ you could do this with secure sessions Yes, but we needed to support safe participation in *insecure* public sessions. >4/ you could use SDR and SIP as tools to initiate the firewall access, >and setup a relay between the outside generalied port, and the inside >one (maybe, as i say on a different mcast addr/port pair for >safety...) - this would be neat, but might not fit quickly with >audited code...as per your toolkit and socks and so on....but its UDP, >so its a lot easier to think through and check than TCP (imho:-) This would be neat. However, we wanted the design of the proxy to be consistent with the rest of the fwtk, which is strongly oriented toward TCP. Kelly From rem-conf-request@es.net Fri Mar 14 15:00:43 1997 Received: from buttle.lcs.mit.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Mar 1997 12:00:01 -0800 Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4) id OAA17589; Fri, 14 Mar 1997 14:58:20 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Kelly Djahandari cc: rem-conf@es.net Subject: Re: socks/mbone firewalls In-reply-to: Your message of "Fri, 14 Mar 1997 12:52:10 EST." <199703141752.MAA25187@clipper.hq.tis.com> Date: Fri, 14 Mar 1997 14:58:20 -0500 Message-ID: <17587.858369500@buttle.lcs.mit.edu> Sender: mjh@buttle.lcs.mit.edu > >4/ you could use SDR and SIP as tools to initiate the firewall access, > >and setup a relay between the outside generalied port, and the inside > >one (maybe, as i say on a different mcast addr/port pair for > >safety...) - this would be neat, but might not fit quickly with > >audited code...as per your toolkit and socks and so on....but its UDP, > >so its a lot easier to think through and check than TCP (imho:-) > >This would be neat. However, we wanted the design of the proxy to be >consistent with the rest of the fwtk, which is strongly oriented toward >TCP. Note that the current SIP spec allows both UDP and TCP access. Mark From rem-conf-request@es.net Fri Mar 14 15:46:09 1997 Received: from csc.com (actually explorer.csc.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Mar 1997 12:45:37 -0800 Received: from ftroy.herndon.csc.com by csc.com with smtp (Smail3.1.29.1 #1) id m0w5dr4-001B6vC; Fri, 14 Mar 97 15:45 EST Message-Id: Comments: Authenticated sender is From: Frank Troy To: rem-conf@es.net Date: Fri, 14 Mar 1997 15:42:50 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: sd, vic, vat, wb installation on SGI Reply-to: ftroy@csc.com X-Confirm-Reading-To: ftroy@csc.com X-pmrqc: 1 Return-receipt-to: ftroy@csc.com Priority: normal X-mailer: Pegasus Mail for Win32 (v2.42) Hello all, I'm installing sd, vic, vat, and wb on an SGI running IRIX 6.2 and I'm having problems. Any suggestions from experienced installers on this platform is welcome. Thanks Frank ------------------------------------------------------------------------ Frank Troy Computer Sciences Corporation ftroy@csc.com From rem-conf-request@es.net Fri Mar 14 17:09:32 1997 Received: from buttle.lcs.mit.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Mar 1997 14:08:51 -0800 Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4) id RAA18115; Fri, 14 Mar 1997 17:07:12 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Kelly Djahandari cc: rem-conf@es.net Subject: Re: socks/mbone firewalls In-reply-to: Your message of "Fri, 14 Mar 1997 12:52:10 EST." <199703141752.MAA25187@clipper.hq.tis.com> Date: Fri, 14 Mar 1997 17:07:12 -0500 Message-ID: <18113.858377232@buttle.lcs.mit.edu> Sender: mjh@buttle.lcs.mit.edu > >4/ you could use SDR and SIP as tools to initiate the firewall access, > >and setup a relay between the outside generalied port, and the inside > >one (maybe, as i say on a different mcast addr/port pair for > >safety...) - this would be neat, but might not fit quickly with > >audited code...as per your toolkit and socks and so on....but its UDP, > >so its a lot easier to think through and check than TCP (imho:-) > >This would be neat. However, we wanted the design of the proxy to be >consistent with the rest of the fwtk, which is strongly oriented toward >TCP. In the current draft, SIP can use both TCP and UDP. Mark ##garbage added for list expander that doesn't like quoted text## ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# From rem-conf-request@es.net Fri Mar 14 19:46:17 1997 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Mar 1997 16:44:26 -0800 Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id QAA06308 for ; Fri, 14 Mar 1997 16:44:14 -0800 (PST) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.6/8.7.3) id QAA00678 for rem-conf@es.net; Fri, 14 Mar 1997 16:44:23 -0800 (PST) Original-Received: by ccm.hf.intel.com (ccmgate 3.2 #7) Fri, 14 Mar 97 16:44:23 PST PP-warning: Illegal Received field on preceding line Date: Fri, 14 Mar 97 16:41:00 PST From: John H Wilson Message-ID: To: rem-conf@es.net Subject: Encrypting RTP streams The following is some text to be included in H.323 that proposes how to apply various modes of encryption to its RTP streams. I have posted it to achieve wider scrutiny...... There are a number of issues involved in how an encryption algorithm may be applied to an RTP stream: - to allow for lost (or out-of-sequence) packets - to pad packets to an appropriate multiple of octets. - to minimize bandwidth demands - for endpoint performance In H.323, encryption is applied just to the RTP payload; the headers remaining in the clear. Since packets can be lost, deciphering the stream must be stateless; each packet being decipherable on its own merits. The cases being considered are: Block algorithms in ECB, CBC, OFB or CFB modes, and Stream algorithms. 1. Block Algorithms a) Initialization vectors Most block modes involve some "chaining". That is, each encryption cycle depends in some way on the output of the previous cycle. Therefore, at the beginning of a packet, some initial block value (usually called an Initialization Vector - IV) must be provided in order to start the encryption process. Independent of how many stream octets are processed on each encryption cycle, the length of the IV is always equal to the length of a block. All modes except Electronic Code Book (ECB) mode require an IV. In all cases, an IV shall be constructed from the first B octets of: (Seq# + Timestamp + Seq#) from the RTP header. b) Padding ECB and CBC modes always process the input stream a block at a time, and, while CFB and OFB can process the input in any number of octets, N (<=B), it is recommended that N=B. [This recommendation is for security reasons in OFB mode (see Schneier, 2nd edition, p205), and for performance]. Two methods are proposed to handle packets whose payload is not a multiple of blocks. i) Ciphertext Stealing[1] for ECB & CBC; "Null pad" for CFB & OFB There is a description of Ciphertext Stealing in Schneier's 2nd edition, p191, p196. With "Null Pad", if the final block is short, it is processed as though it were padded with 0 (in both CFB and OFB, the final operation is an XOR of the final block of plaintext with the some excrypted material). Only the amount of Ciphertext equal to the length of the short block is appended to the encrypted payload. ii) Padding in the manner prescribed by RTP RFC 1889 section 5.1 describes a method of padding in which the payload is padded to a multiple of blocks, the last octet set with the number of padding octets (including the last), and the P bit set in the header. The value of the pad should be determined by the normal convention of the cipher algorithm. It is recommended that all H.Secure implementations must support both schemes. The scheme in use can be deduced as follows: If the P bit is set, then the packet is padded; if the payload is not a multiple of B octets and the P bit is not set, then Ciphertext Stealing or Null Padding applies, else the packet is a multiple of B, and there is no padding. 2. Stream Algorithms Stream algorithms depend on being able to generate identical key- streams at each end, and XORing each plaintext bit with the same key stream bit at each end. Therefore, if packets are lost or re- ordered, the algorithm can get out of synchronization. However, if, for each packet, it were possible to determine the number of preceding bits in the stream, the decryption operation would be able to re-sync. (Packets that are out-of-order by the time they reach the decryption algorithm would have to be discarded). In order to determine the number of preceding bits in the stream, the first 8 octets of the payload shall contain the number of preceding octets in the stream. [Note: there seems to be no way to overload the Sequence number field to provide some of this information. Sequence numbers start with a random value, and cycle every 64K packets.] Reference: [1] J. Daemon, "Cipher and Hash function design", Ph.D. Thesis, Katholieke Universiteit Leuven, Mar 95. From rem-conf-request@es.net Sat Mar 15 11:52:27 1997 Received: from buttle.lcs.mit.edu by osi-west.es.net with ESnet SMTP (PP); Sat, 15 Mar 1997 08:51:49 -0800 Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4) id LAA23371; Sat, 15 Mar 1997 11:43:29 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: John H Wilson cc: rem-conf@es.net Subject: Re: Encrypting RTP streams In-reply-to: Your message of "Fri, 14 Mar 1997 16:41:00 PST." Date: Sat, 15 Mar 1997 11:43:29 -0500 Message-ID: <23369.858444209@buttle.lcs.mit.edu> Sender: mjh@buttle.lcs.mit.edu >In H.323, encryption is applied just to the RTP payload; the headers >remaining in the clear. > of the IV is always equal to the length of a block. All modes > except Electronic Code Book (ECB) mode require an IV. In all > cases, an IV shall be constructed from the first B octets of: > (Seq# + Timestamp + Seq#) from the RTP header. I don't claim to be an encryption expert, but my understanding was that the IV was supposed to be secret unless the first block contains random data. If this is not the case, chained ciphers are weakened significantly. Thus taking the IV from the plain text header doesn't seem to be a good idea without additional precautions. A better bet might be to use a fixed IV and add a random block of dummy data to the front of the payload before encryption. This way the second block which contains predictable data is chained from the random first block rather than from a known IV. Mark From rem-conf-request@es.net Sat Mar 15 12:53:23 1997 Received: from cs.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Sat, 15 Mar 1997 09:52:50 -0800 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA22970; Sat, 15 Mar 1997 12:52:46 -0500 (EST) Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id MAA13889; Sat, 15 Mar 1997 12:52:41 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <332AE1E9.66B9@cs.columbia.edu> Date: Sat, 15 Mar 1997 12:52:41 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Mark Handley CC: John H Wilson , rem-conf@es.net Subject: Re: Encrypting RTP streams References: <23369.858444209@buttle.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Handley wrote: > > >In H.323, encryption is applied just to the RTP payload; the headers > >remaining in the clear. > > > of the IV is always equal to the length of a block. All modes > > except Electronic Code Book (ECB) mode require an IV. In all > > cases, an IV shall be constructed from the first B octets of: > > (Seq# + Timestamp + Seq#) from the RTP header. > > I don't claim to be an encryption expert, but my understanding was > that the IV was supposed to be secret unless the first block contains > random data. If this is not the case, chained ciphers are weakened > significantly. > > Thus taking the IV from the plain text header doesn't seem to be a > good idea without additional precautions. A better bet might be to > use a fixed IV and add a random block of dummy data to the front of > the payload before encryption. This way the second block which > contains predictable data is chained from the random first block > rather than from a known IV. See Kaufman/Perlman/Speciner, "Network Security", p. 83. The book recommends a random IV (not necessarily secret), so that the same plaintext doesn't get encrypted into the same ciphertext. In particular: "A randomly chosen IV guarantees that even if the same message is sent repeatedly, the ciphertext will be completelely different each time. Finally, a randomly chosen IV prevents attackers from supplying chosen plaintext to the underlying encryption algorithm even if they can supply chosen plaintext to the CBC." A random initial message block would have the same effect. Choosing the IV from the *payload* plaintext would defeat this randomization purpose of the IV and you might as well use, say, 0. Given that the same payload transmitted twice is very unlikely to have the same seq. #/ts combination, this seems ok. Schneier (2nd ed., p. 194) says "... So, if there are n blocks, there are n-1 exposed 'IVs,', even if the original IV is kept secret. So there's no reason to keep the IV secret; the IV is just a dummy ciphertext block...". > > Mark Henning From rem-conf-request@es.net Sat Mar 15 15:35:45 1997 Received: from faui40.informatik.uni-erlangen.de by osi-west.es.net with ESnet SMTP (PP); Sat, 15 Mar 1997 12:35:13 -0800 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by faui40.informatik.uni-erlangen.de (8.8.5/8.0.5-FAU) with ESMTP id VAA03479 for ; Sat, 15 Mar 1997 21:35:10 +0100 (MET) From: Toerless Eckert Message-Id: <199703152035.VAA03479@faui40.informatik.uni-erlangen.de> Subject: vic/vat recording tool To: rem-conf@es.net Date: Sat, 15 Mar 1997 21:35:08 +0100 (MET) Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit A stupid question for a change: What's a good interactive tool to record vic/vat sessions ? What's expected to be started from sdr for that purpose ? -- Toerless Eckert Universitaet Erlangen Nuernberg RRZE / IMMD4 Martensstrasse 1 D-91058 Erlangen, Germany Tel.: +49 9131 85 7278 FAX: +49 9131 85 8732 Toerless.Eckert@Informatik.Uni-Erlangen.DE /C=De/A=D400/P=Uni-Erlangen/OU=Informatik/S=Eckert/G=Toerless/ From rem-conf-request@es.net Mon Mar 17 12:19:44 1997 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Mar 1997 09:19:03 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <18306(7)>; Mon, 17 Mar 1997 09:18:35 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177490>; Mon, 17 Mar 1997 08:26:59 -0800 To: Toerless Eckert cc: rem-conf@es.net Subject: Re: vic/vat recording tool In-reply-to: Your message of "Sat, 15 Mar 97 12:35:08 PST." <199703152035.VAA03479@faui40.informatik.uni-erlangen.de> Date: Mon, 17 Mar 1997 08:26:52 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <97Mar17.082659pst.177490@crevenia.parc.xerox.com> I've been using the MBone VCR from http://www.icsi.berkeley.edu/mbone-vcr/. I haven't done enough recording to be sure that it really works well, though, it seems to sometimes have trouble with RTPv2 audio. I use the attached perl script, named record_session, to make the sdr "record" button work. Bill #!/import/misc/bin/perl # # record_session # # An interface between sdr and the MBone VCR. # sdr launches this script with an SDP session description as input. # This script creates an MBone VCR .vcr file out of the session description, # and creates a .cmd file that starts recording immediately, and starts # the MBone VCR with the .cmd file on the command line. # # Bill Fenner 22 Apr 1996 # # # Set the next line to the MBone VCR executable location $vcr = "mbone_vcr"; # You should not need to change anything below this line. require 'ctime.pl'; $ver = "0.9"; $fn = $ARGV[0]; $fn =~ s/\.vcr$//; $vcrfn = $fn . ".vcr"; $cmdfn = $fn . ".cmd"; open(VCR,">$vcrfn") || die "$vcrfn: $!\n"; print VCR "\n"; print VCR "# This file was generated by record_session v$ver\n"; print VCR "session_date=", &ctime(time); $medianum = 1; # I don't know if MBone VCR requires any particular ordering of its file. # Given the SDP fields in the order that sdr outputs them, this loop should # create the .vcr file in the same order as MBone VCR does. while () { chop; ($key,$data) = split(/=/,$_,2); if ($key eq "s") { print VCR "session_name=$data\n"; } elsif ($key eq "i") { print VCR "session_desc=$data\n"; } elsif ($key eq "c") { if ($medianame) { ($mediaip,$mediattl) = ($data =~ m|([0-9.]+)/(\d+)$|); } else { ($ip,$ttl) = ($data =~ m|([0-9.]+)/(\d+)$|); if ($ttl) { print VCR "session_max_ttl=$ttl\n"; } else { print VCR "session_max_ttl=0\n"; # XXX } } } elsif ($key eq "m") { if ($medianame) { print VCR "${medianum}=media_port=$mediaport\n"; print VCR "${medianum}=media_ip=$mediaip\n"; print VCR "${medianum}=media_name=$medianame\n"; print VCR "${medianum}=media_type=$mediatype\n"; print VCR "${medianum}=media_mute=0\n"; print VCR "${medianum}=media_desc=$medianame\n"; print VCR "${medianum}=media_cmd=$mediacmd\n"; print VCR "${medianum}=media_cid=$mediacid\n"; print VCR "${medianum}=media_ttl=$mediattl\n"; $medianum++; undef $medianame; } ($medianame, $mediaport, $type, $fmt) = split(/\s+/, $data); $mediacid = 0; undef $mediatype; undef $mediacmd; undef $mediattl; $mediaip = $ip; if ($type eq "vat") { $mediatype = 2; } elsif ($type =~ /^rtp$/io || $type =~ m|^rtp/avp$|io ) { $mediatype = 1; } else { print STDERR "Warning: don't know about media type $type so "; print STDERR "can't record $medianame media...\n"; undef $medianame; next; } if ($medianame eq "audio") { $mediacmd = "vat"; } elsif ($medianame eq "video") { $mediacmd = "vic"; } else { $mediacmd = "unknown"; } } elsif ($key eq "a") { if ($medianame && $data =~ /id:(\d+)/) { $mediacid = $1; } } } if ($medianame) { print VCR "${medianum}=media_port=$mediaport\n"; print VCR "${medianum}=media_ip=$mediaip\n"; print VCR "${medianum}=media_name=$medianame\n"; print VCR "${medianum}=media_type=$mediatype\n"; print VCR "${medianum}=media_mute=0\n"; print VCR "${medianum}=media_desc=$medianame\n"; print VCR "${medianum}=media_cmd=$mediacmd\n"; print VCR "${medianum}=media_cid=$mediacid\n"; print VCR "${medianum}=media_ttl=$mediattl\n"; } close(VCR); open(CMD,">$cmdfn") || die "$cmdfn: $!\n"; print CMD "# Load the session description file\n"; print CMD "load $vcrfn\n"; print CMD "# Just in case we're being asked to add to an existing file\n"; print CMD "goto end\n"; print CMD "# Allow recording\n"; print CMD "rec_enabled on\n"; print CMD "# and start recording immediately!\n"; print CMD "rec\n"; close(CMD); exec "$vcr -c $cmdfn &"; From rem-conf-request@es.net Mon Mar 17 14:27:31 1997 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Mar 1997 11:26:46 -0800 Received: from ibeam.intel.com (ibeam.jf.intel.com [134.134.208.3]) by ormail.intel.com (8.8.4/8.8.4) with SMTP id LAA02133; Mon, 17 Mar 1997 11:26:26 -0800 (PST) Received: from quasar by ibeam.intel.com with smtp (Smail3.1.28.1 #6) id m0w6i6d-000RTGC; Mon, 17 Mar 97 11:30 PST Message-Id: <1.5.4.32.19970317192640.0097ad5c@ibeam.intel.com> X-Sender: czhu@ibeam.intel.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_858655600==_" Date: Mon, 17 Mar 1997 11:26:40 -0800 To: internet-drafts@ietf.org From: "C. Zhu" Subject: revision of RTP payload format for H.263 video streams, v04 Cc: rem-conf@es.net, czhu@ibeam.jf.intel.com X-Attachments: D:\doc\ietf\rtp\r263id04.txt; --=====================_858655600==_ Content-Type: text/plain; charset="us-ascii" Hi all, Attached please find vision 04 of "RTP Payload Format for H.263 Video Streams", named draft-ietf-avt-rtp-payload-04.txt. Changes for this revision are mostly editorial to make it more readable. If you any comments or questions, please send it to this mailing list or to czhu@ibeam.intel.com. --Chad --=====================_858655600==_ Content-Type: text/plain; charset="us-ascii" Internet Engineering Task Force Audio-Video Transport WG INTERNET-DRAFT C. Zhu Intel Corp. March 15, 1997 Expires: September 15, 1997 RTP Payload Format for H.263 Video Streams Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Abstract This document specifies the payload format for encapsulating an H.263 bitstream in the Real-Time Transport Protocol (RTP). Three modes are defined for the H.263 payload header. An RTP packet can use one of the three modes for H.263 video streams depending on the desired network packet size and H.263 encoding options employed. The shortest H.263 payload header (mode A) supports fragmentation at Group of Block (GOB) boundaries. The long H.263 payload headers (mode B and C) support fragmentation at Macroblock (MB) boundaries. 1. Introduction This document describes a scheme to packetize an H.263 video stream for transport using RTP [1]. H.263 video stream is defined by ITU-T Recommendation H.263 (referred to as H.263 in this document) [4] for video coding at very low data rates. RTP is defined by the Internet Engineering Task Force (IETF) to provide end-to-end network transport functions suitable for applications transmitting real-time data over multicast or unicast network services. Zhu [Page 1] Internet Draft draft-ietf-avt-rtp-payload-04.txt March, 1997 2. Definitions The following definitions apply in this document: CIF: Common Intermediate Format. For H.263, a CIF picture has 352 x 288 pixels for luminance, and 176 x 144 pixels for chrominance. QCIF: Quarter CIF source format with 176 x 144 pixels for luminance and 88 x 72 pixels for chrominance. Sub-QCIF: picture source format with 128 x 96 pixels for luminance and 64 x 48 pixels for chrominance. 4CIF: Picture source format with 704 x 576 pixels for luminance and 352 x 288 pixels for chrominance. 16CIF: Picture source format with 1408 x 1152 pixels for luminance and 704 x 576 pixels for chrominance. GOB: For H.263, a Group of Blocks (GOB) consists of k*16 lines, where k depends on the picture format (k=1 for QCIF, CIF and sub-QCIF; k=2 for 4CIF and k=4 for 16CIF). MB: A macroblock (MB) contains four blocks of luminance and the spatially corresponding two blocks of chrominance. Each block consists of 8x8 pixels. For example, there are eleven MBs in a GOB in QCIF format and twenty two MBs in a GOB in CIF format. 3. Design Issues for Packetizing H.263 Bitstreams H.263 is based on the ITU-T Recommendation H.261 [2] (referred to as H.261 in this document). Compared to H.261, H.263 employs similar techniques to reduce both temporal and spatial redundancy, but there are several major differences between the two algorithms that affect the design of packetization schemes significantly. This section summarizes those differences. 3.1 Optional Features of H.263 In addition to the basic source coding algorithms, H.263 supports four negotiable coding options to improve performance: Advanced Prediction, PB-frames, Syntax-based Arithmetic Coding, and Unrestricted Motion Vectors. They can be used in any combination. Advanced Prediction(AP): One or four motion vectors can be used for some macroblocks in a frame. This feature makes recovery from packet loss difficult, because more redundant information has to be preserved at the beginning of a packet when fragmenting at a macroblock boundary. Zhu [Page 1] Internet Draft draft-ietf-avt-rtp-payload-04.txt March, 1997 PB-frames: Two frames (a P frame and a B frame) are coded into one bitstream with macroblocks from the two frames interleaved. From a packetization point of view, a MB from the P frame and a MB from the B frame must be treated together because each MB for the B frame is coded based on the corresponding MB for the P frame. A means must be provided to ensure proper rendering of two frames in the right order. Also, if part of this combined bitstream is lost, it will affect both frames, and possibly more. Syntax-based Arithmetic Coding (SAC): When the SAC option is used, the resultant run-value pair after quantization of Discrete Cosine Transform (DCT) coefficients will be coded differently from Huffman codes, but the macroblock hierarchy will be preserved. Since context variables are only synchronized after fixed length codes in the bitstream, any fragmentation starting at variable length codes will result in difficulty in decoding in the presence of packet loss without carrying the values of all the context variables in each H.263 payload header. The Unrestricted motion vectors feature allows large range of motion vectors to improve performance of motion compensation for inter-coded pictures. This option also affects packetization because it uses larger range of motion vectors than normal. To enable proper decoding of packets received, without dependency on previous packets, the use of these optional features is signaled in the H.263 payload header, as described in Section 5. 3.2 GOB Numbering In H.263, each picture is divided into groups of blocks (GOB). GOBs are numbered according to a vertical scan of a picture, starting with the top GOB and ending with the bottom GOB. In contrast, a GOB in H.261 is composed of three rows of 16x16 MB for QCIF, and three half-rows of MBs for CIF. A GOB is divided into macroblocks in H.263 and the definition of the macroblocks are the same as in H.261. Each GOB in H.263 can have a fixed GOB header, but the use of the header is optional. If the GOB header is present, it may or may not start on a byte boundary. Byte alignment can be achieved by proper bit stuffing by the encoder, but it is not required by the H.263 bitstream specification [4]. In summary, a GOB in H.263 is defined and coded with finer granularity but with the same source format, resulting in more flexibility for packetization than with H.261. Zhu [Page 2] Internet Draft draft-ietf-avt-rtp-payload-04.txt March, 1997 3.3 Motion Vector Encoding Differential coding is used to code motion vectors as variable length codes. Unlike in H.261, where each motion vector is predicted from the previous MB in the GOB, H.263 employs a more flexible prediction scheme, where one or three candidate predictors could be used depending on the presence of GOB headers. If the GOB header is present in a GOB, motion vectors are coded with reference to MBs in the current GOB only. If a GOB header is not present in the current GOB, three motion vectors must be available to decode one macroblock, where two of them might come from the previous GOB. To correctly decode a whole inter-coded GOB, all the motion vectors for MBs in the previous GOB must be available to compute the predictors or the predictors themselves must be present. The optional use of three motion vector predictors can be a major problem for a packetization scheme like the one defined for H.261 when packetizing at MB boundaries [5]. Consider the case that a packet starts with a MB but the GOB header is not present. If the previous packet is lost, then all the motion vectors needed to predict the motion vectors for the MBs in the current GOB are not available. In order to decode the received MBs correctly, all the motion vectors for the previous GOB or the motion vector predictors would have to be duplicated at the beginning of the packet. This kind of duplication would be very expensive and unacceptable in terms of bandwidth overhead. The encoding strategy of each H.263 CODEC (CODer and DECoder) implementation is beyond the scope of this document, even though it has significant effect on visual quality in the presence of packet loss. However, we strongly recommend use of the GOB header for every GOB at the beginning of a packet to address this problem. 3.4 Macroblock Address As specified by H.261, a macroblock address (MBA) is encoded with a variable length code to indicate the position of a macroblock within a group of MBs in H.261 bitstreams. H.263 does not code the MBA explicitly, but the macroblock address within a GOB is necessary to recover from packet loss when fragmenting at MB boundaries. Therefore, this information must be included in the H.263 payload header for modes (mode B and mode C as described in Section 5) that allow packetization at MB boundaries. Zhu [Page 3] Internet Draft draft-ietf-avt-rtp-payload-04.txt March, 1997 4. Usage of RTP When transmitting H.263 video streams over the Internet, the output of the encoder can be packetized directly. All the bits resulting >from the bitstream including the fixed length codes and variable length codes will be included in the packet. Also multiplexing audio and video signals in the same packet is not accommodated, as UDP and RTP provide a much more efficient way to achieve multiplexing. RTP does not guarantee a reliable and orderly data delivery service, so a packet might get lost in the network. To achieve a best-effort recovery from packet loss, the decoder needs assistance to proceed with decoding of other packets that are received. Thus it is desirable to be able to process each packet independent of other packets. Some frame level information is included in each packet, such as source format and flags for optional features to assist the decoder in operating correctly and efficiently in presence of packet loss. The flags for H.263 optional features also provide information about coding options used in H.263 video bitstreams that can be used by session management tools. H.263 video bitstreams will be carried as payload data within RTP packets. A new H.263 payload header is defined in section 5 on the H.263 payload header. This section defines the usage of RTP fixed header and H.263 video packet structure. 4.1 RTP Header Usage Each RTP packet starts with a fixed RTP header [1]. The following fields of the RTP fixed header are used for H.263 video streams: Marker bit (M bit): The Marker bit of the RTP fixed header is set to 1 when the current packet carries the end of current frame; Set to 0 otherwise. Payload Type (PT): The Payload Type shall specify H.263 video payload format with decimal value 34. Timestamp: The RTP timestamp encodes the sampling instance of the first video frame contained in the RTP data packet. The RTP timestamp may be the same on successive packets if a video frame occupies more than one packet. For H.263 video streams, the RTP timestamp is based on a 90 kHz clock, the same as the RTP timestamp for H.261 video streams [5]. 4.2 Video Packet Structure For each RTP packet, the RTP fixed header is followed by the H.263 payload header, which is followed by the standard H.263 compressed bitstream [4]. Zhu [Page 4] Internet Draft draft-ietf-avt-rtp-payload-04.txt March, 1997 The size of the H.263 payload header is variable depending on modes used as detailed in the next section. The layout of an RTP H.263 video packet is shown as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H.263 payload header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H.263 bitstream | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. H.263 Payload Header For H.263 video streams, each RTP packet carries only one H.263 video packet. The H.263 payload header is always present for each H.263 video packet. Three formats (mode A, mode B and mode C) are defined for H.263 payload header. In mode A, a H.263 payload header of four bytes is present before actual compressed H.263 video bitstream in a packet. It allows fragmentation at GOB boundaries. In mode B, a eight byte H.263 payload header is used and each packet starts at MB boundaries without the PB-frames option. Finally, a twelve byte H.263 payload header is defined in mode C to support fragmentation at MB boundaries for frames that are coded with the PB-frames option. The mode of each H.263 payload header is indicated by the F and P fields in the header. Packets of different modes can be intermixed. All client application are required to be able to receive packets in any mode, but decoding of mode C packets is optional because the PB-frames feature is optional. In this section, the H.263 payload format is shown as rows of 32-bit words. Each word is transmitted in network byte order. Whenever a field represents a numeric value, the most significant bit is at the left of the field. 5.1 Mode A In this mode, an H.263 bitstream will be packetized on a GOB boundary or a picture boundary. Mode A packets always start with the H.263 picture start code [4] or a GOB, but do not necessarily contain complete GOBs. Four bytes are used for the mode A H.263 payload header. The H.263 payload header definition for mode A is shown as follows with F=0. Zhu [Page 5] Internet Draft draft-ietf-avt-rtp-payload-04.txt March, 1997 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|P|SBIT |EBIT | SRC |I|U|S|A|R |DBQ| TRB | TR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ F: 1 bit The flag bit indicates the mode of the payload header. F=0, mode A; F=1, mode B or mode C depending on P bit defined below. P: 1 bit Optional PB-frames mode as defined by the H.263 [4]. "0" implies normal I or P frame, "1" PB-frames. When F=1, P also indicates modes: mode B if P=0, mode C if P=1. SBIT: 3 bits Start bit position specifies number of most significant bits that shall be ignored in the first data byte. EBIT: 3 bits End bit position specifies number of least significant bits that shall be ignored in the last data byte. SRC : 3 bits Source format specifies the resolution of the frame as defined by the H.263 [4]. I: 1 bit. Picture coding type, defined by H.263[4], "0" is intra-coded, "1" is inter-coded. U: 1 bit Unrestricted Motion Vector option as defined by H.263 [4], "0" off, "1" on. S: 1 bit Optional Syntax-based Arithmetic Coding option as defined by the H.263 [4], 0" off, "1" on. A: 1 bit Optional Advanced Prediction option as defined by H.263 [4], "0" off, "1" on. R: 4 bits Reserved, must be set to zero. Zhu [Page 6] Internet Draft draft-ietf-avt-rtp-payload-04.txt March, 1997 DBQ: 2 bits Differential quantization parameter used to calculate quantizer for the B frame based on quantizer for the P frame, when PB-frames option is used. The value should be the same as DBQUANT defined by H.263 [4]. Set to zero if PB-frames option is not used. TRB: 3 bits Temporal Reference for the B frame as defined by H.263 [4]. Set to zero if PB-frames option is not used. TR: 8 bits Temporal Reference for the P frame as defined by H.263 [4]. Set to zero if the PB-frames option is not used. 5.2 Mode B In this mode, an H.263 bitstream can be fragmented at MB boundaries. Whenever a packet starts at a MB boundary, this mode shall be used without PB-frames option. Mode B packets are intended for a GOB whose size is larger than the maximum packet size allowed in the underlying protocol, thus making it impossible to fit one or more complete GOBs in a packet. This mode can only be used without the PB-frames option. Mode C as defined in the next section can be used to fragment H.263 bitstreams at MB boundaries with the PB-frames option. The H.263 payload header definition for mode B is shown as follows with F=1 and P=0: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|P|SBIT |EBIT | SRC | QUANT | GOBN | MBA |R | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|U|S|A| HMV1 | VMV1 | HMV2 | VMV2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following fields are defined the same as in mode A: F, P, SBIT, EBIT, SRC, I, U, S and A. Other fields are defined as follows: QUANT: 5 bits Quantization value for the first MB coded at the starting of the packet. Set to 0 if the packet begins with a GOB header. This is the equivalent of GQUANT defined by the H.263 [4]. GOBN: 5 bits GOB number in effect at the start of the packet. GOB number is specified differently for different resolutions. See H.263 [4] for details. MBA: 9 bits The absolute address of the first MB within its GOB, counting from 0. Zhu [Page 7] Internet Draft draft-ietf-avt-rtp-payload-04.txt March, 1997 HMV1, VMV1: 7 bits each. Horizontal and vertical motion vector predictors for the first MB in this packet [4]. When four motion vectors are used for current MB with advanced prediction option, these would be the motion vector predictors for block number 1 in the MB. Each 7 bits field encodes a motion vector predictor in half pixel resolution as a 2's complement number. HMV2, VMV2: 7 bits each. Horizontal and vertical motion vector predictors for block number 3 in the first MB in this packet when four motion vectors are used with the advanced prediction option. This is needed because block number 3 in the MB needs different motion vector predictors from other blocks in the MB. These two fields are not used when the MB only has one motion vector. See the H.263 [4] for block organization in a macroblock. Each 7 bits field encodes a motion vector predictor in half pixel resolution as a 2's complement number. R : 2 bits Reserved, must be set to zero. 5.3 Mode C In this mode, an H.263 bitstream is fragmented at MB boundaries of P frames with the PB-frames option. It is intended for those GOBs whose sizes are larger than the maximum packet size allowed in the underlying protocol when PB-frames option is used. The H.263 payload header definition for mode C is shown as follows with F=1 and P=1: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|P|SBIT |EBIT | SRC | QUANT | GOBN | MBA |R | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|U|S|A| HMV1 | VMV1 | HMV2 | VMV2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR |DBQ| TRB | TR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following fields are defined the same as in mode B: F, P, SBIT, EBIT, SRC, QUANT, GOBN, MBA, R, I, U, S, A, HMV1, VMV1, HMV2, VMV2. The rest of the fields (TR, DBQ, TRB) are defined the same as in mode A, except field RR. RR is reserved and its value must be zero. Zhu [Page 8] Internet Draft draft-ietf-avt-rtp-payload-04.txt March, 1997 5.4 Selection of Modes for the H.263 Payload Header Packets carrying H.263 video streams with different modes can be intermixed. The modes shall be selected carefully based on network packet size, H.263 coding options and underlying network protocols. More specifically, mode A shall be used for packets starting with a GOB or the H.263 picture start code [4], and mode B or C shall be used whenever a packet has to start at a MB boundary. Mode B or C are necessary for those GOBs with sizes larger than network packet size. We strongly recommend use of mode A whenever possible. The major advantage of mode A over mode B and C is its simplicity. The H.263 payload header is smaller than mode B and C. Transmission overhead is reduced and the savings may be very significant when working with very low data rates or relatively small packet sizes. Another advantage of mode A is that it simplifies error recovery in the presence of packet loss. The internal state of a decoder can be recovered at GOB boundaries instead of having to synchronize with MBs as in mode B and C. The GOB headers and the picture start code are easy to identify, and their presence will normally cause a H.263 decoder to re-synchronize its internal states. Requiring a decoder to synchronize its internal states at MBs introduces extra overhead and complexity for the decoder. Finally, we would like to stress that recovery from packet loss depends on a decoder's ability to use the information provided in the H.263 payload header within RTP packets. 6. References [1] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. RTP : A Transport Protocol for Real-Time Applications, RFC 1889. IETF, 1996. [2] International Telecommunication Union. Video Codec for Audiovisual Services at p x 64 kbits/s, ITU-T Recommendation H.261, 1993. [3] H. Schulzrinne. RTP Profile for Audio and Video Conference with Minimal Control, RFC 1890. IETF, 1996. [4] International Telecommunication Union. Video Coding for Low Bitrate Communication, ITU-T Recommendation H.263, 1996 Zhu [Page 9] Internet Draft draft-ietf-avt-rtp-payload-04.txt March, 1997 [5] T. Turletti, C. Huitema. RTP Payload Format for H.261 Video Streams, RFC 2032. IETF, 1996. 7. Author's Address C. "Chad" Zhu Mail Stop: JF2-78 Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA Email: czhu@ibeam.intel.com Tel: (503) 264-8849 Fax: (503) 264-6067 Zhu [Page 10] --=====================_858655600==_ Content-Type: text/plain; charset="us-ascii" --=====================_858655600==_-- From rem-conf-request@es.net Mon Mar 17 14:28:41 1997 Received: from nobozo.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Mar 1997 11:28:14 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id LAA01708 for ; Mon, 17 Mar 1997 11:02:53 -0800 Date: Mon, 17 Mar 1997 11:02:53 -0800 Message-Id: <199703171902.LAA01708@nobozo.CS.Berkeley.EDU> X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: Jerrlyn Iwata Subject: [Reminder] Berkeley Multimedia & Graphics Seminar Berkeley Multimedia and Graphics Seminar (Wednesday March 19, 1997 12:30-2:00 PDT 405 Soda Hall) "The Prince and the Pauper, or, is content really King?" John Taysom Reuters, Ltd. MBONE BROADCAST BEGINS AT 12.40 PDT (GMT - 8 HOURS) From rem-conf-request@es.net Mon Mar 17 20:31:52 1997 Received: from INET-04-IMC.microsoft.com (actually mail4.microsoft.com) by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Mar 1997 17:31:06 -0800 Received: by INET-04-IMC with Internet Mail Service (5.0.1457.3) id ; Mon, 17 Mar 1997 17:32:50 -0800 Message-ID: <503A2A3C2932CF118D8800805FD44E1802F46AD3@red-68-msg.dns.microsoft.com> From: Eric Fleischman To: "'mjh@isi.edu'" , "'rem-conf@es.net'" Subject: RE: In Defense of Interleaved Data Formats Date: Mon, 17 Mar 1997 17:29:52 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) I was tempted to let this message slide by (now that I am finally reading the messages sent while I was on vacation) but in the interest of accuracy (Truth) I couldn't do so in this instance. We have found that "de-interleaving" is very easy to handle at the client. It can be accomplished quickly and efficiently. All our interleaved media objects are pre-time-stamped. Our algorithm for interleaved data is much simpler than what you envision. Thus, these particular comments may be good jousting targets but don't seem to be born out in "real life" - or at least, in our experience to date. As a reminder, my position is that there are times when interleaving makes the best sense and times when segregated streams make the best sense. Thus, I am not speaking against segregated streams but rather am merely saying that these particular arguments are not valid. Anyway, a seventh reason to use Interleaved Data Streams are for situations in which you wish to constrain the total streamed bandwidth to a certain maximum data rate while simultaneously ensuring that that entire capacity is used (i.e., multimedia content to not dip much below a pre-specified data rate to ensure that the "most multimedia stuff" can be jammed into that constrained capacity target). -----Original Message----- From: Mark Handley [SMTP:mjh@isi.edu] Sent: Friday, March 07, 1997 2:40 PM To: Sampo Syreeni Cc: Eric Fleischman; 'rem-conf@es.net' Subject: Re: In Defense of Interleaved Data Formats >Indeed. But always having to do multiple streams is a true problem for >simple clients. I think I'm taking the position that interlaced data >streams as a unit must be supported as much as simple streams do. They >truly are the most common ones today. And expect nothing less when digital >TV takes on... No. An interleaved client has to de-interleave the streams and timestamp them, then decode them (different media have different decode delays) then buffer to perform playout adjustment for audio-device clock skew, different decode times, network jitter and audio device buffer latencies, then actually play the media streams out. A non-interleaved client does the same thing, except the streams arrive de-interleaved and pre-timestamped. In either model, you can move the playout buffering around somewhat, but it doesn't change the general principle. Interleaved streams are common because switched circuits are. We don't have that constraint. >But if the original format of the data is >interleaved, it would be nice if it could be used as-is as just another >stream. Especially since there are interleaved protocols out there. Depends if the original format was designed to cope with packet loss. H.221 for example is not, and takes many seconds to recover after a packet loss. It's consituent H.261 and audio codings can however be packetised to cope quite well with loss. Just because your data originated interleaved doesn't mean it's a good idea to transmit it that way. Mark From rem-conf-request@es.net Tue Mar 18 04:17:07 1997 Received: from rap.cefriel.it by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Mar 1997 01:16:28 -0800 Received: from tempra (tempra [131.175.5.19]) by rap.cefriel.it (8.8.5/8.8.5) with SMTP id KAA22955; Tue, 18 Mar 1997 10:12:01 +0100 (MET) Sender: campanal@mailer.cefriel.it Message-ID: <332E54E9.794BDF32@mailer.cefriel.it> Date: Tue, 18 Mar 1997 09:40:09 +0100 From: Giuseppe Fabio Campanale Organization: CEFRIEL - COGEFO X-Mailer: Mozilla 3.01 (X11; I; SunOS 4.1.4 sun4c) MIME-Version: 1.0 To: vic@ee.lbl.gov CC: rem-conf@es.net Subject: Problems with VIC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I retreived the latest version of vic distribution file (v 2.8) and compiled it successfully on Sun SS20 equipped with SunVideo. Problems arise when I try to transmit images using (M)Jpeg encoding: all I can get is a "Bus error" or "Segmentation fault" message. Apart *this*, everything works fine. Any hint ? Has it anything to do with a "buggy" jpeg.cc module or the like ? If so, is there (where ?) any patch available ? Or, maybe, is it my fault ? Thank you very much for your kind attention. Best Regards. -- Fabio Campanale From rem-conf-request@es.net Tue Mar 18 05:13:22 1997 Received: from mailhub.axion.bt.co.uk by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Mar 1997 02:12:47 -0800 Received: from rambo.futures.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Tue, 18 Mar 1997 10:10:42 +0000 Received: from mussel.drake.bt.co.uk (actually mussel.futures.bt.co.uk) by rambo.futures.bt.co.uk with SMTP (PP); Tue, 18 Mar 1997 10:11:41 +0000 Received: by mussel.drake.bt.co.uk with Microsoft Exchange (IMC 4.0.837.3) id <01BC3383.E9C05680@mussel.drake.bt.co.uk>; Tue, 18 Mar 1997 10:05:31 -0000 Message-ID: From: Benoit Gaillard To: "'rem-conf@es.net'" Subject: Trigger join messages Date: Tue, 18 Mar 1997 10:05:45 -0000 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Encoding: 18 TEXT Hi everybody, Thanks for all this interesting issues discussed on this Email list ... one personal concern : I would like to trigger join messages on behalf of external events. VIC or VAT applications do not seem easy to modify, do you agree? Are there other ways of triggering join messages in the multicast receiver, rather than using multicast applications? Thanks for your interest, Benoit. ________________________________________________________ Benoit GAILLARD - B29 Rm138 Phone : 00-44-(0)1473-647609 ________________________________________________________ From rem-conf-request@es.net Tue Mar 18 05:25:11 1997 Received: from cloud9.net by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Mar 1997 02:24:10 -0800 Received: from [168.100.203.200] (tearouts.dialup.cloud9.net [168.100.203.200]) by cloud9.net (8.8.5/cloud9-1.0) with ESMTP id EAA19417; Tue, 18 Mar 1997 04:14:30 -0500 (EST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-to: Please.reply.via.fax.or.smail@fax.number.or.smail.address.shown.below.Thank.you Approved: by tearouts@cloud9.net X-Priority: 1 (Highest) Date: Tue, 18 Mar 1997 01:49:11 -1812 To: tearouts@cloud9.net From: tearouts@cloud9.net Subject: ===>> FREE 1 yr USA Magazine Sub sent worldwide-270+ Choices! Up to $64.00 value! FOR MORE INFO: please "cut out" the below form on the "cut" lines shown, and fax it, for the fastest reply to: 718-227-9125 (this is a fax # in the USA) or send via smail (first class mail or airmail) to: Tempting Tear-Outs Att. Free-catalogue-by-email Dept 3835 Richmond Ave. Suite #200 Staten Island NY 10312-3828 USA SORRY, BUT.... our software is not set up to accept forms via return email; WE CAN ONLY acknowledge forms sent in via fax or smail. --> IMPORTANT complete directions, to ensure that you get a reply, and more info follow, below the reply form and the catalogue options. *------------cut here/begin-------------------------------------------* Name: Internet email address: Smail home address: City-State-Zip: Country: Work Tel. #: Work Fax #: Home Tel. #: Home Fax #: How did you hear about us (name of person/company who referred you or the area of the internet that you saw us mentioned in): Referred by: Tempting Tear-Outs 031497-l Name of USA mags you currently get on the newsstand or in the store: Name of USA mags you currently get on a subscription basis, through the mail: Name of USA mags you would like price quotes on when we call you: Catalogue version desired (list number of choice below): *------------cut here/end--------------------------------------------* CATALOGUE VERSION CHOICES: 1. This version can be read by everyone, no matter what type of computer you use, or what type of software you use. It is a simple format, with just our entire catalogue pasted into the body of a single email message, 316K in size. If you use pine or elm on a unix system or an advanced software version such as Eudora Pro 3.0 or later, you will most likely receive it as a single email message. However, if your software limits incoming email messages to a certain size, say 32K or so, then your software will split it into multiple email message parts. Whether you receive it as a single email message or multiple part email messages, you can easily paste it into one whole text document with your word processor, in about 10 minutes or so. 2. For more advanced computer users: attached plain ascii text file ~316K - you must know how to download an attached text file and then be able to locate it on your hard drive or system home directory; it can then be opened with any pc or mac word processing software. If in doubt, don't ask for this version. This isn't for internet *newbies.* Better to order option 1 and spend a few minutes pasting them into one whole text document with your word processor, than to waste hours trying to figure how to deal with this option. This version is great for doing keyword searches and jumping around within the catalogue with your word processing software, if your normal email reading software doesn't allow this. VERY IMPORTANT DIRECTIONS TO ENSURE THAT YOU GET A REPLY: 1. you must call from an "unblocked number," ie. one that is not blocked >from caller id. We are very sorry for this requirement, but our fax software requires this before it allows an incoming fax call to connect. If you have a blocked number, you must first unblock it. In most cases this means dialing *82 from a touch-tone phone (or 1182 from a rotary phone) before you dial 1-718-227-9125. NOTE: If you are not sure if your number is blocked, just try dialing our fax # normally. If you don't get a recording telling you your number is blocked, your number has been transmitted and you may press the start button on your fax when you hear the fax tone from our fax. 2. no reply forms can be accepted by email....only via fax or smail. 3. your form must be typewritten or printed out on your computer printer before you fax it; sorry, but *no* handwritten forms will be acknowledged. If you can't find someone with a typewriter or a computer printer, we apologize for not being able to reply to you. 4. faxes with cover pages will be rejected. You must send *only* the reply form. 5. forms not *completely* filled in will not be acknowledged. 6. you will receive a reply within 1 business day directly from the company making the offer via email. Therefore you must have an email address. If you read this message, then you must have an email address, or access to one, at least. :-) 7. your fax must not exceed 1 page in length. Faxes of 2 or more pages will be sensed, then auto-terminated and deleted. Your fax goes directly onto our 5.0 gigabyte hard drive and we must limit all incoming faxes to 1 page. 8. all faxes must begin with: *------------cut here/begin-------------------------------------------* and must end with: *------------cut here/end--------------------------------------------* 9. Any fax not conforming to this format will be sensed by our software, then auto-terminated and deleted from the hard drive, before any human ever gets to see it. 10. The type on your fax must be dark and legible. If in doubt, please print it out darker before faxing it in. If we can't read it, we can't reply to you or send you our FREE catalogue. :-( 11. If this all seems too complicated for faxing, just do it the old fashioned way via smail!!! WHO WE ARE: Tempting Tear-Outs is an advertising company that brings potential new customers to the companies they advertise for. MORE ABOUT THE COMPANY MAKING THE FREE OFFER: The company making the offer is a magazine subscription agency based in the USA. They have over 1,500 popular USA titles available to be shipped to *any* country, including of course, to anywhere in the USA! They offer a FREE 1 yr. subscription to your choice of over 270 of the titles in their catalogue to any new customer using them for the first time. The dollar value of the freebies, based on the subscription prices directly >from the publishers, ranges from $6.97 all the way up to $50.00! For new customers in the USA, there is no charge for FPH (foreign postage & handling), so the freebie is 100% free! For new customers living overseas, the only charge on the freebie would be for the FPH (foreign postage & handling). Their president has been in the magazine subscription business since 1973 and they are very customer-service oriented. They will even help you with address changes on your magazines, even if you move from one country to another country. They have thousands of happy customers in over 59 countries. Their price guarantee is very simple: they guarantee that their subscription prices are the lowest available and they will BEAT any legitimate, verifiable offer before you pay them or match it afterwards, by refunding you the difference in price PLUS the cost of the postage stamp you would use sending in the special offer to them, even 6 months after you pay them, as long as it was current at the time of your offer. Does that sound fair? Wouldn't it be great if everything you bought came with that price guarantee? Sometimes they are less than half of the next best deal out there, sometimes just a little cheaper, but always you get the lowest rates without having to shop around. With 1,500 titles on their list, they would like to think that they have also the best selection around! Within the USA, for their USA customers, they are cheaper than all their competitors and even the publishers themselves. This is their price guarantee. The 1 yr. freebie that you get with your first order is completely free! Overseas, (even after you factor in the cost of the FPH (foreign postage & handling) and the conversion from USA Dollars to your currency), on the average, they are generally around one-fourth to one-half of what the newsstands overseas charge locally for USA magazines. On some titles they are as little as one-tenth of what the newsstands charge. They are also the cheapest subscription source for delivery overseas, including directly >from the publishers themselves! Some publishers don't even offer subscriptions overseas.........but overseas subscriptions are this company's specialty! They feel that magazines should not be a luxury overseas. In the USA, people buy magazines and then toss them after reading them for just a few minutes or hours. They are so cheap in the USA! Well, this company would like to make it the same way for their overseas members. They are also cheaper than all their competitors in the USA and overseas, including the publishers themselves! It is also *highly unlikely* you will find any of their USA competitors calling you overseas, in order to offer that personal touch, just to sell you a couple of magazines! But that is what this company specializes in and loves doing! Around one-half their business comes from overseas, so they are very patient with new members who only speak limited English as a 2nd language. Subscription prices quoted for overseas consist of the subscription price, plus the FPH. You add the two together and that is your total cost. The exception is the 1 yr. freebie you get with your first order. On that title, you pay *only* the FPH for the 1 yr. term. Their prices are so cheap because when you deal with them, you cut-out all the middlemen. HERE IS HOW YOU CAN GET MORE INFO AND GET STARTED WITH THEM: Simply fax or smail back to us the reply form listed at the top of this message. We will then forward your form on to the subscription agency. They will then email their "big and juicy" catalogue to you, in whichever of the four formats you chose. The catalogue is FREE and makes for hours of fascinating reading, on its own. It includes the complete list of freebies, a complete list of all the titles they sell, as well as detailed descriptions on most of the titles, along with lists of titles by category of interest and their terms of sale. They will then give you a friendly, no-pressure, no obligation, 5-minute call to go over how they work and to answer any questions that you might have, as well as give you up-to-the minute price quotes on any titles you might be considering. They will call you in whatever country you live in, taking the time difference into account. As they like to emphasize the personal touch they give to each new customer, all first-time orders can only be done via phone, so they can answer all your questions completely and personally. Once you have placed your first order via phone, you will be able to place future orders and make inquiries on your account, get price quotes, etc., all via email, if that is most convenient for you. Within the USA, they accept payment via check over the phone, Mastercard, Visa and American Express. Overseas, they accept Mastercard, Visa and American Express, even if your credit card is a local one in local currency! That's our introduction of our client that we represent. We hope that we have piqued your interest and that you will take the next step to get their free catalogue! Thank you for your time and interest. -- Tempting Tear-Outs. For more info on advertising rates, please write us on your company letterhead, w/business card, via smail to: Tempting Tear-Outs, 3835 Richmond Ave. Suite #200, Staten Island NY 10312-3828, USA. From rem-conf-request@es.net Tue Mar 18 14:50:23 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Mar 1997 11:49:39 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id LAA02365 for ; Tue, 18 Mar 1997 11:49:54 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma002354; Tue Mar 18 11:49:32 1997 Received: by hille.msri.org (8.7/MSRI) id LAA15128; Tue, 18 Mar 1997 11:49:27 -0800 (PST) Date: Tue, 18 Mar 1997 11:49:27 -0800 (PST) Message-Id: <199703181949.LAA15128@hille.msri.org> To: rem-conf@es.net From: m1 Reply-to: m1@msri.org Subject: Curtis Greene "Representations, Posets, and Moebius Functions" MBone Broadcast Announcement ---------------------------- Title: Curtis Greene "Representations, Posets, and Moebius Functions" Date: Mar 25, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/lecturenotes/97/greene/ Description: Curtis Greene's talk from MSRI sponsor's day, February 28, 1997. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Mar 18 14:52:26 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Mar 1997 11:51:39 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id LAA02429 for ; Tue, 18 Mar 1997 11:51:54 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma002417; Tue Mar 18 11:51:08 1997 Received: by hille.msri.org (8.7/MSRI) id LAA15162; Tue, 18 Mar 1997 11:51:05 -0800 (PST) Date: Tue, 18 Mar 1997 11:51:05 -0800 (PST) Message-Id: <199703181951.LAA15162@hille.msri.org> To: rem-conf@es.net From: m1 Reply-to: m1@msri.org Subject: Andrew Casson "Geometric Topology in Dimension 3" MBone Broadcast Announcement ---------------------------- Title: Andrew Casson "Geometric Topology in Dimension 3" Date: Mar 26, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/lecturenotes/97/casson/ Description: Andrew Casson's talk from MSRI sponsor's day, February 28, 1997. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Mar 18 14:54:32 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Mar 1997 11:53:40 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id LAA02500 for ; Tue, 18 Mar 1997 11:53:55 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma002474; Tue Mar 18 11:52:59 1997 Received: by hille.msri.org (8.7/MSRI) id LAA15196; Tue, 18 Mar 1997 11:52:56 -0800 (PST) Date: Tue, 18 Mar 1997 11:52:56 -0800 (PST) Message-Id: <199703181952.LAA15196@hille.msri.org> To: rem-conf@es.net From: m1 Reply-to: m1@msri.org Subject: Curt McMullen "Geometrically Infinite Kleinian Groups" MBone Broadcast Announcement ---------------------------- Title: Curt McMullen "Geometrically Infinite Kleinian Groups" Date: Mar 27, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/lecturenotes/97/mcmullen/ Description: Curt McMullen's talk from Computational and Algorithmic Methods in 3-Dimensional Topology Workshop , March 13, 1997. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Wed Mar 19 14:11:01 1997 Received: from hplms26.hpl.hp.com by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Mar 1997 11:10:25 -0800 Received: from hplabsz.hpl.hp.com by hplms26.hpl.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3+HPL1.1S) id AA096888606; Wed, 19 Mar 1997 11:10:08 -0800 Received: by hplabsz.hpl.hp.com (1.37.109.20/15.5+ECS 3.3+HPL1.1) id AA003378608; Wed, 19 Mar 1997 11:10:08 -0800 From: deleon@hplabsz.hpl.hp.com (Laura de Leon) Message-Id: <9703191110.ZM335@hplabsz.hpl.hp.com> Date: Wed, 19 Mar 1997 11:10:07 -0800 X-Mailer: Z-Mail (3.0.0 15dec93) To: baylisa@baylisa.org, sage-members@usenix.org, rem-conf@es.net Subject: (BayLISA: Paul Vixie on BIND Version 8 Cc: deleon@hplabsz.hpl.hp.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 The BayLISA group meets monthly to discuss topics of interest to systems and network administrators. The meetings are free and open to the public. BayLISA holds monthly meetings on the third Thursday of each month at 7:30 PM PST. We meet at Cisco building J in San Jose, on Tasman Drive near First street. See www.baylisa.org for more information. The meetings are also broadcast via MBONE. Schedule -------- March 20 Paul Vixie BIND Version 8 is in final public beta testing. It has a completely new configuration file format, many new features including dynamic update and online change notification, and a better build mechanism than BIND 4.9.5. Paul will give a brief overview of the new config syntax, new features, and will tell once again why we didn't call it BIND Version 5. Paul will also describe the Internet Software Consortium and its other software projects [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:/location 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. From rem-conf-request@es.net Thu Mar 20 10:17:20 1997 Received: from ietf.org by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Mar 1997 07:16:48 -0800 Received: from ietf.ietf.org by ietf.org id aa13691; 20 Mar 97 9:56 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-payload-03.txt Date: Thu, 20 Mar 1997 09:56:18 -0500 Sender: cclark@ietf.org Message-ID: <9703200956.aa13691@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for H.263 Video Streams Author(s) : C. Zhu Filename : draft-ietf-avt-rtp-payload-03.txt Pages : 10 Date : 03/19/1997 This document specifies the payload format for encapsulating an H.263 bitstream in the Real-Time Transport Protocol (RTP). Three modes are defined for the H.263 payload header. An RTP packet can use one of the three modes for H.263 video streams depending on the desired network packet size and H.263 encoding options employed. The shortest H.263 payload header (mode A) supports fragmentation at Group of Block (GOB) boundaries. The long H.263 payload headers (mode B and C) support fragmentation at Macroblock (MB) boundaries. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-payload-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-rtp-payload-03.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-payload-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970319134105.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-payload-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-payload-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970319134105.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Thu Mar 20 13:11:31 1997 Received: from oyt.oulu.fi by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Mar 1997 10:10:51 -0800 Received: from oyt.oulu.fi (shem@localhost [127.0.0.1]) by oyt.oulu.fi (8.8.5/8.8.1) with ESMTP id UAA26673; Thu, 20 Mar 1997 20:10:47 +0200 (EET) Message-Id: <199703201810.UAA26673@oyt.oulu.fi> X-Mailer: exmh version 2.0gamma 1/24/96 To: rem-conf@es.net cc: ekumedia@sun3.oulu.fi, tkuusiva@syy.oulu.fi Subject: Event announcement: Finnish POP Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Mar 1997 20:10:46 +0200 From: Janne Himanka MBone Broadcast Announcement ---------------------------- Title: A Grand Day Out: A Slice of the Finnish Pop/Rock Scene Date: Apr 14 1997 Time: 14:00 GMT 4 hours Contact: shem@katiska.oulu.fi URL: http://katiska.oulu.fi/xmission.html Description: A few videos of some of the more promising Finnish bands. We will also test the Nordic MBone topology. Please contact shem@katiska.oulu.fi if something more serious and academic collides with this, and we will settle a more suitable time. Janne Himanka From rem-conf-request@es.net Thu Mar 20 20:23:06 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Mar 1997 17:22:26 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id RAA14942 for ; Thu, 20 Mar 1997 17:22:42 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma014917; Thu Mar 20 17:22:08 1997 Received: by hille.msri.org (8.7/MSRI) id RAA16114; Thu, 20 Mar 1997 17:22:07 -0800 (PST) Date: Thu, 20 Mar 1997 17:22:07 -0800 (PST) Message-Id: <199703210122.RAA16114@hille.msri.org> To: rem-conf@es.net From: m1 Reply-to: m1@msri.org Subject: Donald Knuth "Graph Drawing from a User's Perspective" MBone Broadcast Announcement ---------------------------- Title: Donald Knuth "Graph Drawing from a User's Perspective" Date: Apr 01, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/lecturenotes/96/knuth/ Description: Donald Knuth's 9/18/96 from Graph Drawing 96 at MSRI. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Thu Mar 20 20:25:01 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Mar 1997 17:24:28 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id RAA15048 for ; Thu, 20 Mar 1997 17:24:43 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma015040; Thu Mar 20 17:24:32 1997 Received: by hille.msri.org (8.7/MSRI) id RAA16148; Thu, 20 Mar 1997 17:24:32 -0800 (PST) Date: Thu, 20 Mar 1997 17:24:32 -0800 (PST) Message-Id: <199703210124.RAA16148@hille.msri.org> To: rem-conf@es.net From: m1 Reply-to: m1@msri.org Subject: Donald Knuth "Some Research Problems for Combinatorialists" MBone Broadcast Announcement ---------------------------- Title: Donald Knuth "Some Research Problems for Combinatorialists" Date: Apr 02, 1997 Time: 08:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/lecturenotes/97/knuth/ Description: Donald Knuth's 1/27/97 talk in the MSRI Combinatorics seminar. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Thu Mar 20 20:27:01 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Mar 1997 17:26:27 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id RAA15141 for ; Thu, 20 Mar 1997 17:26:43 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma015122; Thu Mar 20 17:25:57 1997 Received: by hille.msri.org (8.7/MSRI) id RAA16182; Thu, 20 Mar 1997 17:25:56 -0800 (PST) Date: Thu, 20 Mar 1997 17:25:56 -0800 (PST) Message-Id: <199703210125.RAA16182@hille.msri.org> To: rem-conf@es.net From: m1 Reply-to: m1@msri.org Subject: T. Y. Lam "Kap" MBone Broadcast Announcement ---------------------------- Title: T. Y. Lam "Kap" Date: Apr 03, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/lecturenotes/97/lam/ Description: T. Y. Lam reviews the works and life of MSRI director emeritus Irving Kaplansky on the occasion of his 80th birthday. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Thu Mar 20 23:06:07 1997 Received: from RUTGERS.EDU by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Mar 1997 20:04:33 -0800 Received: (from daemon@localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id XAA05929; Thu, 20 Mar 1997 23:04:28 -0500 To: ru-comp-dev-ietf-rem-conf@rutgers.edu Path: usenet From: m1@msri.org (m1) Newsgroups: ru.comp.dev.ietf.rem-conf Subject: Donald Knuth "Some Research Problems for Combinatorialists" Date: 20 Mar 1997 23:04:26 -0500 Organization: Rutgers University Lines: 29 Sender: news@RUTGERS.EDU Message-ID: <5gt1ca$5p6$1@rutgers.rutgers.edu> MBone Broadcast Announcement ---------------------------- Title: Donald Knuth "Some Research Problems for Combinatorialists" Date: Apr 02, 1997 Time: 08:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/lecturenotes/97/knuth/ Description: Donald Knuth's 1/27/97 talk in the MSRI Combinatorics seminar. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Thu Mar 20 23:56:08 1997 Received: from RUTGERS.EDU by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Mar 1997 20:55:30 -0800 Received: (from daemon@localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id XAA07322; Thu, 20 Mar 1997 23:55:26 -0500 To: ru-comp-dev-ietf-rem-conf@rutgers.edu Path: usenet From: m1@msri.org (m1) Newsgroups: ru.comp.dev.ietf.rem-conf Subject: Donald Knuth "Graph Drawing from a User's Perspective" Date: 20 Mar 1997 23:55:24 -0500 Organization: Rutgers University Lines: 29 Sender: news@RUTGERS.EDU Message-ID: <5gt4bs$74m$1@rutgers.rutgers.edu> MBone Broadcast Announcement ---------------------------- Title: Donald Knuth "Graph Drawing from a User's Perspective" Date: Apr 01, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/lecturenotes/96/knuth/ Description: Donald Knuth's 9/18/96 from Graph Drawing 96 at MSRI. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Fri Mar 21 00:06:51 1997 Received: from RUTGERS.EDU by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Mar 1997 21:05:35 -0800 Received: (from daemon@localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id AAA07777; Fri, 21 Mar 1997 00:05:33 -0500 To: ru-comp-dev-ietf-rem-conf@rutgers.edu Path: usenet From: m1@msri.org (m1) Newsgroups: ru.comp.dev.ietf.rem-conf Subject: T. Y. Lam "Kap" Date: 21 Mar 1997 00:05:30 -0500 Organization: Rutgers University Lines: 29 Sender: news@RUTGERS.EDU Message-ID: <5gt4uq$7iu$1@rutgers.rutgers.edu> MBone Broadcast Announcement ---------------------------- Title: T. Y. Lam "Kap" Date: Apr 03, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/lecturenotes/97/lam/ Description: T. Y. Lam reviews the works and life of MSRI director emeritus Irving Kaplansky on the occasion of his 80th birthday. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Fri Mar 21 14:30:14 1997 Received: from cheerios.cisco.com by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Mar 1997 11:29:30 -0800 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id LAA04522 for ; Fri, 21 Mar 1997 11:29:27 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Mar 1997 11:29:06 -0800 To: rem-conf@es.net From: Steve Deering Subject: portable MBone terminal? Has anyone managed to put together a PC laptop system adequate to serve as a portable MBone terminal and demo machine? The necessary pieces would presumably be: - a PC laptop, with built-in pointing device suitable for drawing in wb. - some flavor of BSD Unix with support for IP multicast and for mrouted 3.8 (in case it has to tunnel to reach the MBone) - mrouted, mtrace, sdr, vat, vic, and wb, all working correctly - a 10BASE-T ethernet port - a (VGA? SVGA?) video output port to drive an LCD projector or overhead projector panel - analog audio output port for connecting to, e.g., a hotel meeting room PA system - built-in microphone, or audio input port to accept an external microphone. - (optional) video input port and tiny camera If any of you has succeeded in putting together such a system, I would love to get a "parts list" and any other advice/suggestions/handholding you'd be willing to share. Steve From rem-conf-request@es.net Fri Mar 21 17:31:23 1997 Received: from out1.ibm.net by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Mar 1997 14:30:37 -0800 Received: (from uucp@localhost) by out1.ibm.net (8.6.9/8.6.9) id WAA71341; Fri, 21 Mar 1997 22:30:30 GMT Date: Fri, 21 Mar 1997 22:30:30 GMT Message-Id: <199703212230.WAA71341@out1.ibm.net> Received: from slip198.advantis.net.il(192.115.219.202) by out1.ibm.net via smap (V1.3mjr) id smaMzsDmb; Fri Mar 21 22:30:05 1997 X-Sender: lkudo@pop01.ny.us.ibm.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: videophone@es.net From: Leora Kudo Subject: PC-desktop videoconferencing Cc: rem-conf@es.net I am searching for any relevant, updated information regarding : 1. number of ISDN lines available worldwide (with country break-down i.e. US, Europe, Asia-Pacific) 2. ISDN-based PC desktop videoconferencing \ teleconferencing systems : 2.1. market estimates and forecasts 2.1.1. number of units sold 2.1.2. number of units forecasted for 1997 and 1998 2.3. predicted growth of ISDN based videocommunications equipment revenue (not network) 2.4. major players in this arena and their respective market share (with country break-down i.e. US, Europe, Asia-Pacific) 2.5. unit pricing 2.6. main applications 2.7. trends 3. PC desktop videoconferencing over INTERNET and POTS 3.1. market estimates and forecasts 3.2. major players in this arena and their respective market share 3.3. trends 4. Fast Modems 4.1. market estimates and forecasts 4.2. major players If you can guide me to any web sites, send me information or provide me with any pointers, I will be more than thankful. Until then, thanking you in advance, Regards, Leora From rem-conf-request@es.net Fri Mar 21 18:10:37 1997 Received: from RUTGERS.EDU by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Mar 1997 15:09:18 -0800 Received: (from daemon@localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id SAA11179; Fri, 21 Mar 1997 18:09:12 -0500 To: ru-comp-dev-ietf-rem-conf@rutgers.edu Path: usenet From: deering@cisco.com (Steve Deering) Newsgroups: ru.comp.dev.ietf.rem-conf Subject: portable MBone terminal? Date: 21 Mar 1997 18:09:09 -0500 Organization: Rutgers University Lines: 32 Sender: news@RUTGERS.EDU Message-ID: <5gv4el$at8$1@rutgers.rutgers.edu> Has anyone managed to put together a PC laptop system adequate to serve as a portable MBone terminal and demo machine? The necessary pieces would presumably be: - a PC laptop, with built-in pointing device suitable for drawing in wb. - some flavor of BSD Unix with support for IP multicast and for mrouted 3.8 (in case it has to tunnel to reach the MBone) - mrouted, mtrace, sdr, vat, vic, and wb, all working correctly - a 10BASE-T ethernet port - a (VGA? SVGA?) video output port to drive an LCD projector or overhead projector panel - analog audio output port for connecting to, e.g., a hotel meeting room PA system - built-in microphone, or audio input port to accept an external microphone. - (optional) video input port and tiny camera If any of you has succeeded in putting together such a system, I would love to get a "parts list" and any other advice/suggestions/handholding you'd be willing to share. Steve From rem-conf-request@es.net Fri Mar 21 20:35:35 1997 Received: from RUTGERS.EDU by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Mar 1997 17:34:46 -0800 Received: (from daemon@localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id UAA15426; Fri, 21 Mar 1997 20:34:42 -0500 To: ru-comp-dev-ietf-rem-conf@rutgers.edu Path: usenet From: lkudo@ibm.net (Leora Kudo) Newsgroups: ru.comp.dev.ietf.rem-conf Subject: PC-desktop videoconferencing Date: 21 Mar 1997 20:34:39 -0500 Organization: Rutgers University Lines: 29 Sender: news@RUTGERS.EDU Message-ID: <5gvcvf$f1v$1@rutgers.rutgers.edu> I am searching for any relevant, updated information regarding : 1. number of ISDN lines available worldwide (with country break-down i.e. US, Europe, Asia-Pacific) 2. ISDN-based PC desktop videoconferencing \ teleconferencing systems : 2.1. market estimates and forecasts 2.1.1. number of units sold 2.1.2. number of units forecasted for 1997 and 1998 2.3. predicted growth of ISDN based videocommunications equipment revenue (not network) 2.4. major players in this arena and their respective market share (with country break-down i.e. US, Europe, Asia-Pacific) 2.5. unit pricing 2.6. main applications 2.7. trends 3. PC desktop videoconferencing over INTERNET and POTS 3.1. market estimates and forecasts 3.2. major players in this arena and their respective market share 3.3. trends 4. Fast Modems 4.1. market estimates and forecasts 4.2. major players If you can guide me to any web sites, send me information or provide me with any pointers, I will be more than thankful. Until then, thanking you in advance, Regards, Leora From rem-conf-request@es.net Fri Mar 21 22:36:35 1997 Received: from elang.stts.ac.id by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Mar 1997 19:35:52 -0800 Received: from localhost (albertaw@localhost) by elang.stts.ac.id (8.7.5/8.6.9) with SMTP id KAA12751; Sat, 22 Mar 1997 10:37:23 +0700 Date: Sat, 22 Mar 1997 10:37:23 +0700 (JVT) From: Albertus Agung Wardana To: Internet-Drafts@ietf.org cc: rem-conf@es.net Subject: Re: I-D ACTION:draft-ietf-avt-rtp-payload-03.txt In-Reply-To: <9703200956.aa13691@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 20 Mar 1997 Internet-Drafts@ietf.org wrote: > A Revised Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Audio/Video Transport > Working Group of the IETF. > > Title : RTP Payload Format for H.263 Video Streams > Author(s) : C. Zhu > Filename : draft-ietf-avt-rtp-payload-03.txt > Pages : 10 > Date : 03/19/1997 > > This document specifies the payload format for encapsulating an H.263 > bitstream in the Real-Time Transport Protocol (RTP). Three modes are > defined for the H.263 payload header. An RTP packet can use one of the > three modes for H.263 video streams depending on the desired network packet > size and H.263 encoding options employed. The shortest H.263 payload > header (mode A) supports fragmentation at Group of Block (GOB) boundaries. > The long H.263 payload headers (mode B and C) support fragmentation at > Macroblock (MB) boundaries. > > Internet-Drafts are available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-avt-rtp-payload-03.txt". > A URL for the Internet-Draft is: > ftp://ds.internic.net/internet-drafts/draft-ietf-avt-rtp-payload-03.txt > > Internet-Drafts directories are located at: > > o Africa: ftp.is.co.za > > o Europe: ftp.nordu.net > ftp.nis.garr.it > > o Pacific Rim: munnari.oz.au > > o US East Coast: ds.internic.net > > o US West Coast: ftp.isi.edu > > Internet-Drafts are also available by mail. > > Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-ietf-avt-rtp-payload-03.txt". > > NOTE: The mail server at ds.internic.net can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e., documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version > of the Internet-Draft. > From rem-conf-request@es.net Sat Mar 22 11:01:06 1997 Received: from relay0.jaring.my by osi-west.es.net with ESnet SMTP (PP); Sat, 22 Mar 1997 08:00:10 -0800 Received: from walsin.UUCP (root@localhost) by relay0.jaring.my (8.6.13/8.6.12) with UUCP id XAA07108; Sat, 22 Mar 1997 23:50:26 +0800 Received: by walsin.com.my (UUPC/extended 1.12p); Sat, 22 Mar 1997 23:31:39 +0200 Message-ID: <33344fbb.walsin@walsin.com.my> From: ShouJen To: videophone@es.net, rem-conf@es.net Date: Sat, 22 Mar 1997 22:54:16 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Video Format Reply-to: sjn@walsin.com.my X-Confirm-Reading-To: sjn@walsin.com.my X-pmrqc: 1 Priority: normal X-mailer: Pegasus Mail for Win32 (v2.42a) Hi everybody, This probably sounds like a newbie question to you guys, pls put in your comments. In videoconferencing, video codec plays a huge role. I learn that there is quite a number of video codec technology around today, such as H.261 for standard interoperability, M-JPEG, Indeo, etc. As the camera captures the frames and before the frames are compressed, what sort of video format is used? What's the relationship between H.261 and CIF? Can I say CIF files are compression files of H.261? -------------------------------------------------------------- Shou-Jen Ng Walsin Technology Corporation (M) Sdn. Bhd. Voice: 603-9857800 Fax : 603-9857011 email : sjn@walsin.com.my From rem-conf-request@es.net Sat Mar 22 13:18:57 1997 Received: from RUTGERS.EDU by osi-west.es.net with ESnet SMTP (PP); Sat, 22 Mar 1997 10:18:24 -0800 Received: (from daemon@localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id NAA12196; Sat, 22 Mar 1997 13:18:22 -0500 To: ru-comp-dev-ietf-rem-conf@rutgers.edu Path: usenet From: sjn@walsin.com.my (ShouJen) Newsgroups: ru.comp.dev.ietf.rem-conf Subject: Video Format Date: 22 Mar 1997 13:18:21 -0500 Organization: Rutgers University Lines: 21 Sender: news@RUTGERS.EDU Message-ID: <5h17pd$bt1$1@rutgers.rutgers.edu> Hi everybody, This probably sounds like a newbie question to you guys, pls put in your comments. In videoconferencing, video codec plays a huge role. I learn that there is quite a number of video codec technology around today, such as H.261 for standard interoperability, M-JPEG, Indeo, etc. As the camera captures the frames and before the frames are compressed, what sort of video format is used? What's the relationship between H.261 and CIF? Can I say CIF files are compression files of H.261? -------------------------------------------------------------- Shou-Jen Ng Walsin Technology Corporation (M) Sdn. Bhd. Voice: 603-9857800 Fax : 603-9857011 email : sjn@walsin.com.my From rem-conf-request@es.net Sat Mar 22 21:13:57 1997 Received: from mail.msy.bellsouth.net by osi-west.es.net with ESnet SMTP (PP); Sat, 22 Mar 1997 18:13:23 -0800 Received: from LOCALNAME (d00067.msy.bellsouth.net [207.53.20.68]) by mail.msy.bellsouth.net (8.7.5/8.7.3) with SMTP id VAA00923; Sat, 22 Mar 1997 21:15:23 -0500 (EST) Message-ID: <3334AE64.1BFD@BellSouth.Net> Date: Sat, 22 Mar 1997 20:15:33 -0800 From: Gary O'Neal Reply-To: goneal@comm.net Organization: CommTech X-Mailer: Mozilla 3.01 (Win95; I; 16bit) MIME-Version: 1.0 To: videophone@es.net, rem-conf@es.net Subject: DTVC Co Research Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To the Group: Over the past year, I, personally, have had two very disagreeable employment/representative relationships with start-up videoconferencing equipment companies: 1. Visual Communications Network, Ltd (VCN) (NASDAQ/OTC-BB: BNET) (or Intermedia Net, Inc) 2. Visual Telephone International(VTI) (NASDAQ/OTC-BB: VTPI) Since both of these companies have exhibited at DTVC and COMNET in the Last year, I am curious as to whether or not any of the group members had any contact with either or both. To any investors/potential investors who read these lists, how were you handled by the corporate management? To the suppliers, carriers and DTVC OEMs of VCN, I'm doing some research so any info would be appreciated....Anonymous remailers will be accepted. As both of these organs have publically stated that they provide the "Most Advanced" DTVC equipment available on the market, I figure that some group members may have run across them. Thanks Gary From rem-conf-request@es.net Sat Mar 22 23:14:40 1997 Received: from RUTGERS.EDU by osi-west.es.net with ESnet SMTP (PP); Sat, 22 Mar 1997 20:13:59 -0800 Received: (from daemon@localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id XAA25831; Sat, 22 Mar 1997 23:13:55 -0500 To: ru-comp-dev-ietf-rem-conf@rutgers.edu Path: usenet From: goneal@comm.net ("Gary O'Neal") Newsgroups: ru.comp.dev.ietf.rem-conf Subject: DTVC Co Research Date: 22 Mar 1997 23:13:53 -0500 Organization: CommTech Lines: 22 Sender: news@RUTGERS.EDU Message-ID: <3334AE64.1BFD@BellSouth.Net> To the Group: Over the past year, I, personally, have had two very disagreeable employment/representative relationships with start-up videoconferencing equipment companies: 1. Visual Communications Network, Ltd (VCN) (NASDAQ/OTC-BB: BNET) (or Intermedia Net, Inc) 2. Visual Telephone International(VTI) (NASDAQ/OTC-BB: VTPI) Since both of these companies have exhibited at DTVC and COMNET in the Last year, I am curious as to whether or not any of the group members had any contact with either or both. To any investors/potential investors who read these lists, how were you handled by the corporate management? To the suppliers, carriers and DTVC OEMs of VCN, I'm doing some research so any info would be appreciated....Anonymous remailers will be accepted. As both of these organs have publically stated that they provide the "Most Advanced" DTVC equipment available on the market, I figure that some group members may have run across them. Thanks Gary From rem-conf-request@es.net Sun Mar 23 12:22:36 1997 Received: from venus.Sun.COM by osi-west.es.net with ESnet SMTP (PP); Sun, 23 Mar 1997 09:22:03 -0800 Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA07453 for ; Sun, 23 Mar 1997 09:22:02 -0800 Received: from valathar.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA14102; Sun, 23 Mar 1997 09:21:57 -0800 Received: by valathar.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA20425; Sun, 23 Mar 1997 09:21:07 -0800 Date: Sun, 23 Mar 1997 09:21:07 -0800 From: Michael.Speer@Eng.Sun.COM (Michael F. Speer) Message-Id: <199703231721.JAA20425@valathar.eng.sun.com> To: rem-conf@es.net Subject: AVT meetings at April IETF Cc: Michael.Speer@Eng.Sun.COM How many times are we meeting in Memphis? Thanks, Michael From rem-conf-request@es.net Sun Mar 23 14:57:38 1997 Received: from RUTGERS.EDU by osi-west.es.net with ESnet SMTP (PP); Sun, 23 Mar 1997 11:56:49 -0800 Received: (from daemon@localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id OAA23021; Sun, 23 Mar 1997 14:56:45 -0500 To: ru-comp-dev-ietf-rem-conf@rutgers.edu Path: usenet From: Michael.Speer@Eng.Sun.COM (Michael F. Speer) Newsgroups: ru.comp.dev.ietf.rem-conf Subject: AVT meetings at April IETF Date: 23 Mar 1997 14:56:43 -0500 Organization: Rutgers University Lines: 5 Sender: news@RUTGERS.EDU Message-ID: <199703231721.JAA20425@valathar.eng.sun.com> How many times are we meeting in Memphis? Thanks, Michael From rem-conf-request@es.net Sun Mar 23 21:20:27 1997 Received: from plains.nodak.edu by osi-west.es.net with ESnet SMTP (PP); Sun, 23 Mar 1997 18:19:55 -0800 Received: (from hoag@localhost) by plains.nodak.edu (8.8.5/8.8.5) id UAA04467; Sun, 23 Mar 1997 20:19:50 -0600 (CST) Date: Sun, 23 Mar 1997 20:19:49 -0600 (CST) From: Marty Hoag To: rem-conf@es.net Subject: Test Message Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is only a test. I've been getting duplicates of rem-conf mail this weekend which seems to be coming from Rutgers. This message is being sent at the request of the postmaster there. Thank you. Marty Hoag hoag@plains.nodak.edu From rem-conf-request@es.net Mon Mar 24 04:52:54 1997 Received: from gateway.wfa.digital.ie (actually wf10.wfa.digital.ie) by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Mar 1997 01:52:06 -0800 Received: by gateway.wfa.digital.ie; (8.7.3/1.3/10May95) id LAA20926; Mon, 24 Mar 1997 11:04:14 GMT From: Dermot Tynan Message-Id: <9703240952.AA28316@karpov.wfa.digital.ie> Subject: Re: Video Format To: sjn@walsin.com.my Date: Mon, 24 Mar 1997 09:52:17 +0000 (GMT) Cc: videophone@es.net, rem-conf@es.net In-Reply-To: <33344fbb.walsin@walsin.com.my> from "ShouJen" at Mar 22, 97 10:54:16 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit ShouJen wrote: > > In videoconferencing, video codec plays a huge role. I learn that > there is quite a number of video codec technology around today, such > as H.261 for standard interoperability, M-JPEG, Indeo, etc. As the > camera captures the frames and before the frames are compressed, what > sort of video format is used? The video format prior to compression is by and large irrelevant, except in how it pertains to the size and quality of the compressed image. The most common format is CCIR 601, which is the international broadcast standard for digital representation of video signals. It uses an 8-bit luminance and two 8-bit chrominance channels, with a standard sample rate (13.5MHz) regardless of whether the signal is NTSC-encoded or PAL-encoded. In most cases, the chrominance channels are subsampled at half the luminance rate, known as 4:2:2. The frame size is usually quoted as 720x480x29.97 or 720x576x25, representing the number of horizontal lines, vertical lines, and frames per second. The first is NTSC and the second is PAL. Yes, the NTSC standard does not use an integer number of frames per second. On the other hand, if you have a quickcam or some sort of digital CCD mini camera, the data may never start out in NTSC/PAL, and can be delivered directly to the codec in its native format. > What's the relationship between H.261 and CIF? Can I say CIF files > are compression files of H.261? H.261 is a DCT-based compression standard specifically for video conferencing. CIF on the other hand, is the Common Image Format as defined by CCIR 601. In answer to your second question, you can say that a H.261 file is the compressed version of a CIF file. - Der -- Dermot Tynan +353 91 754608 dtynan@wfa.digital.ie DTN: 822-4608 AltaVista Internet Software, Galway, Ireland From rem-conf-request@es.net Mon Mar 24 10:53:23 1997 Received: from nanotsu.kobe-u.ac.jp by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Mar 1997 07:52:38 -0800 Received: (from oka@localhost) by nanotsu.kobe-u.ac.jp (8.6.12+2.5Wb3/3.3W9) id AAA07413; Tue, 25 Mar 1997 00:56:28 +0900 Message-Id: <199703241556.AAA07413@nanotsu.kobe-u.ac.jp> Reply-To: oka@kobe-u.ac.jp To: rem-conf@es.net, mbone@ISI.EDU cc: infocom411@ckp.or.jp Subject: Broadcasting of Infocom'97 Mime-Version: 1.0 Content-Type: text/plain;charset="ISO-2022-JP" Date: Tue, 25 Mar 1997 00:56:27 +0900 From: Koji OKAMURA Cyber Kansai is pleased to announce the MBONE broadcast of Infocom'97 >from Kobe on April 7-11,1997. Including Gigabit Network Workshop, keynotes by Vinton Serf (MCI) and Toshiharu Aoki (NTT), panels and sessions. Broadcasting of recorded material is also available for US and Europe. Date: 7-11 April, 1997 Time: 4/7 (Mon) 9:00 - 17:00 GMT+9 and 14:00 - 22:00 PST (recorded) Gigabit Networking Workshop 4/9 (Wed) 8:00 - 17:00 GMT+9 and 13:00 - 22:00 PST (recorded) Keynotes, Sessions and Panel 4/10 (Thu) 8:30 - 17:00 GMT+9 and 13:30 - 22:00 PST (recorded) Sessions and Panel 4/11 (Fri) 8:30 - 17:00 GMT+9 and 13:30 - 22:00 PST (recorded) Sessions and Panel Title: Infocom' 97 from Kobe, Japan URL: http://www.ieee.org/comsoc/infocom. Contact: oka@kobe-u.ac.jp Best regards, Cyber Kansai (http://www.ckp.or.jp). From rem-conf-request@es.net Mon Mar 24 12:07:18 1997 Received: from hil-img-2.compuserve.com by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Mar 1997 09:06:33 -0800 Received: by hil-img-2.compuserve.com (8.6.10/5.950515) id MAA02904; Mon, 24 Mar 1997 12:06:22 -0500 Date: Mon, 24 Mar 1997 06:19:01 -0500 From: "H. DO-DUY" <106025.3357@compuserve.com> Subject: Vat sources for windows To: vat Message-ID: <199703240619_MC2-132B-481A@compuserve.com> Hello, I'm trying to make an ethernet conferencing tool based upon VAT 4.0b2. I've retrieved the appropriate archives, and tried to undersant the code, but it seems to be quite difficult, because it is very few commented. Does anybody know where i could find some documentation on the vat coding ? I tried to e-mail the people who created vat, but i can't get any reply. Thanks a lot. Rodolphe PETIT SEEE 24, march, 1997, Toulouse, FRANCE E-mail : 106025.3357@compuserve.com From rem-conf-request@es.net Mon Mar 24 12:52:43 1997 Received: from RUTGERS.EDU by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Mar 1997 09:52:03 -0800 Received: from agni.nuko.com ([207.82.229.31]) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) with ESMTP id MAA24212 for ; Mon, 24 Mar 1997 12:51:49 -0500 Received: (from vinay@localhost) by agni.nuko.com (8.7.5/8.6.12) id JAA28798; Mon, 24 Mar 1997 09:51:21 -0800 (PST) From: Vinay Bannai Message-Id: <199703241751.JAA28798@agni.nuko.com> Subject: Re: Video Format To: sjn@walsin.com.my (ShouJen) Date: Mon, 24 Mar 1997 09:51:21 -0800 (PST) Cc: ru-comp-dev-ietf-rem-conf@rutgers.edu In-Reply-To: <5h17pd$bt1$1@rutgers.rutgers.edu> from "ShouJen" at Mar 22, 97 01:18:21 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text According to ShouJen: > > Hi everybody, > > This probably sounds like a newbie question to you guys, pls put in > your comments. > > In videoconferencing, video codec plays a huge role. I learn that > there is quite a number of video codec technology around today, such > as H.261 for standard interoperability, M-JPEG, Indeo, etc. As the > camera captures the frames and before the frames are compressed, what > sort of video format is used? It depends on the encoding device used and the country you are in. In US, it is NTSC, in most parts of Europe it is PAL (France uses SECAM, I think). NTSC uses 30 frames/second and PAL uses 24 frames/second. > > What's the relationship between H.261 and CIF? Can I say CIF files > are compression files of H.261? CIF stands for Common Intermediate Format (CIF). This a just a video source input format. There are others too, like SIF and CCIR601. For example, if you are using CIF video input, typically it means you are using 352x288 resolution. It has nothing to do with compression and is not the compression file. H.261 uses CIF and QCIF (quarter CIF) video source input formats. Mpeg-1 uses SIF (source input format) which uses 525x625 resolution. Hope this helps. -- Vinay Bannai E-mail: vinay@agni.nuko.com (408)-526-0280 x 275 (Work) http://agni.nuko.com/~vinay From rem-conf-request@es.net Mon Mar 24 13:40:51 1997 Received: from nobozo.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Mar 1997 10:39:39 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id KAA09435 for ; Mon, 24 Mar 1997 10:39:38 -0800 Date: Mon, 24 Mar 1997 10:39:38 -0800 Message-Id: <199703241839.KAA09435@nobozo.CS.Berkeley.EDU> X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: Jerrlyn Iwata Subject: [Reminder] Berkeley Multimedia & Graphics Seminar Berkeley Multimedia and Graphics Seminar Wednesday April 2, 1997 12:30-2:00 PDT 405 Soda Hall "PC vs. TV : The Battle for Eyeballs" Stephen C. Beck Focus Enhancements Inc. MBONE BROADCAST BEGINS AT 12.40 PDT (GMT - 8 HOURS) From rem-conf-request@es.net Mon Mar 24 14:28:09 1997 Received: from ns1.okcom.net by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Mar 1997 11:26:48 -0800 Received: from [208.132.198.56] (pm1-s23.okcom.net [208.132.198.56]) by ns1.okcom.net (8.7.6/8.7.3) with ESMTP id JAA10481; Mon, 24 Mar 1997 09:24:16 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-to: Please.reply.via.fax.or.via.smail@fax.number.or.smail.address.shown.below.Thank.You Approved: by ts@oknet.com Approved-by: ts@oknet.com X-Priority: 1 (Highest) Date: Mon, 24 Mar 1997 01:43:21 -1812 To: ts@okcom.net From: ts@okcom.net Subject: a very interesting free offer From rem-conf-request@es.net Mon Mar 24 14:47:42 1997 Received: from lhc.nlm.nih.gov by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Mar 1997 11:46:52 -0800 Received: from billings.csb by lhc.nlm.nih.gov (SMI-8.6/SMI-SVR4) id OAA28095; Mon, 24 Mar 1997 14:46:13 -0500 Received: by billings.csb (SMI-8.6/SMI-SVR4) id OAA01443; Mon, 24 Mar 1997 14:43:15 -0500 Date: Mon, 24 Mar 1997 14:43:15 -0500 From: rodgers@nlm.nih.gov (R. P. C. Rodgers) Message-Id: <199703241943.OAA01443@billings.csb> To: rem-conf@es.net, mbone@ISI.EDU Subject: 7-11 April is going to be tight on the MBONE (Was: Broadcasting of Infocom'97) Cc: infocom411@ckp.or.jp, oka@kobe-u.ac.jp, dem@hep.net, likavec@igd.fhg.de X-Sun-Charset: US-ASCII Dear Colleagues, The announcement from Kobe indicates that there will be at least four conferences of international scope contending for MBONE bandwidth during the week of 7-11 April. WWW6 and CHEP '97 have announced to this group many weeks ago and are actively advertising at the moment via sd/sdr. I don't remember seeing a posting to these mail lists from the IETF, but it is widely known that they plan on multicasting their traditional two concurrent sessions that week. We at WWW6 had also hoped to send out two parallel tracks. CHEP and Kobe may be using slightly different time slots, but add all of this together and it is going to be a rather tight week, requiring lots of coordination and good humor all around. This highlights several broader issues: 1) Scheduling and priorities. I know that we started advertising on the various MBONE calendars, these mail lists, and with sdr many weeks back. CHEP started doing so about 7-10 days ago. I may have missed email to these lists from IETF, but they are still not on sdr. Kobe just announced today. I am perfectly willing to work as we have in the past, trying best to set up machine and telephone communications between these four groups to try to coordinate to keep to the ancient and honorable "gentleperson's agreement" of not using more total bandwidth that the total of two concurrent A/V sessions, and treating the 4 events as "peers," regardless of how or when they announced their plans publically, but based on past events, just trying to coordinate two meetings can be a tricky task. If we have many more weeks like 7-11 April, are we going to have to get more serious about enforcing some rules of priority, based on advanced reservations, and perhaps some discussion of relative priorities? I'd hate to get into this business, but will it be necessary? 2) Discussion of how international conferences might create temporary CBONEs (Conference backbones) that might allow concurrent conferences to occur with less mutual interference, perhaps getting their traffic off of the "public" Internet backbones. This might even be coupled with (shudder) participation fees for remote sites to defray conference costs (of course, charges would be hard to require in the absence of some reasonable guaranteed level of service). In principle, I would assume that widespread implementation of the appropriate multicast routing standards would obviate the need for a "CBONE" (or not?). Some of these ideas might be pure crock (I'm not pushing them, just trying to engage some of our better minds in discussing the underlying issues!). Perhaps some fodder hear from our colleagues at IETF beer BOFs, if nothing else... 8^) Best Regards (and drink a beer for me!), Rick Rodgers > From oka@nanotsu.kobe-u.ac.jp Mon Mar 24 11:26:48 1997 > Reply-To: oka@kobe-u.ac.jp > To: rem-conf@es.net, mbone@ISI.EDU > cc: infocom411@ckp.or.jp > Subject: Broadcasting of Infocom'97 > Mime-Version: 1.0 > Date: Tue, 25 Mar 1997 00:56:27 +0900 > From: Koji OKAMURA > > Cyber Kansai is pleased to announce the MBONE broadcast of Infocom'97 > from Kobe on April 7-11,1997. Including Gigabit Network Workshop, > keynotes by Vinton Serf (MCI) and Toshiharu Aoki (NTT), panels and > sessions. Broadcasting of recorded material is also available for US > and Europe. > > Date: > 7-11 April, 1997 > > Time: 4/7 (Mon) 9:00 - 17:00 GMT+9 and 14:00 - 22:00 PST (recorded) > Gigabit Networking Workshop > 4/9 (Wed) 8:00 - 17:00 GMT+9 and 13:00 - 22:00 PST (recorded) > Keynotes, Sessions and Panel > 4/10 (Thu) 8:30 - 17:00 GMT+9 and 13:30 - 22:00 PST (recorded) > Sessions and Panel > 4/11 (Fri) 8:30 - 17:00 GMT+9 and 13:30 - 22:00 PST (recorded) > Sessions and Panel > > Title: > Infocom' 97 from Kobe, Japan > > URL: > http://www.ieee.org/comsoc/infocom. > > > Contact: > oka@kobe-u.ac.jp > > Best regards, > Cyber Kansai (http://www.ckp.or.jp). > From rem-conf-request@es.net Mon Mar 24 17:50:12 1997 Received: from buttle.lcs.mit.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Mar 1997 14:47:33 -0800 Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4) id RAA04885; Mon, 24 Mar 1997 17:45:37 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: rodgers@nlm.nih.gov (R. P. C. Rodgers) cc: rem-conf@es.net, oka@kobe-u.ac.jp, dem@hep.net, likavec@igd.fhg.de Subject: Re: 7-11 April is going to be tight on the MBONE (Was: Broadcasting of Infocom'97) In-reply-to: Your message of "Mon, 24 Mar 1997 14:43:15 EST." <199703241943.OAA01443@billings.csb> Date: Mon, 24 Mar 1997 17:45:37 -0500 Message-ID: <4883.859243537@buttle.lcs.mit.edu> Sender: mjh@buttle.lcs.mit.edu >The announcement from Kobe indicates that there will be at least four >conferences of international scope contending for MBONE bandwidth during >the week of 7-11 April. Fortunately they're all in different timezones, so the overlap is not as bad as it could be unless you want to listen to all of them. The problem is the rebroadcasts that people are discussing. These could always be moved to a different week - the potential audience is likely to be larger if it's not split between sessions. According to all the ISPs present at the MBoned WG at the last IETF, no major ISP is running rate-limiting anymore, and we've regularly seen traffic rates above the old nominal 512Kbps. The Mbone is slowly growing up. It *should* be able to handle four simultaneous conferences. But lets not push our luck... Mark From rem-conf-request@es.net Mon Mar 24 18:48:23 1997 Received: from rizzo.infobahnos.com by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Mar 1997 15:47:50 -0800 Received: from [204.19.114.38] (ppp-0128.infobahnos.com [204.19.114.38]) by rizzo.infobahnos.com (8.7.6/A/UX 3.1) with ESMTP id SAA10236; Mon, 24 Mar 1997 18:47:38 -0500 (EST) Date: Mon, 24 Mar 1997 18:47:38 -0500 (EST) Message-Id: In-Reply-To: <199703241943.OAA01443@billings.csb> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rodgers@nlm.nih.gov (R. P. C. Rodgers), rem-conf@es.net, mbone@ISI.EDU From: sprinter@infobahnos.com Subject: QUERY: Publicly accessible MBone sites Cc: infocom411@ckp.or.jp, oka@kobe-u.ac.jp, dem@hep.net, likavec@igd.fhg.de Dear list members, Are there any publicly accessible MBone sites? I know of private networks using and broadcasting on it but was wondering if there are any universities, research centers or organizations who generously offer access to broadcast of tune in to the MBone from their offices. -- JOSEE M. PROULX Sprinter Consulting 3601 Ste-Famille St. Ste 1003 Montreal, Quebec H2X 2L6 1-514-844-5304 (telephone) 1-514-844-5133 (facsimile) sprinter@infobahnos.com (e-mail) From rem-conf-request@es.net Tue Mar 25 02:47:19 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Mar 1997 23:46:44 -0800 Received: from port1.precept.com by precept.com (SMI-8.6/SMI-SVR4) id XAA28794; Mon, 24 Mar 1997 23:37:07 -0800 Date: Mon, 24 Mar 1997 23:44:11 -0800 (PST) From: Stephen Casner Reply-To: Stephen Casner To: "Michael F. Speer" cc: rem-conf@es.net Subject: Re: AVT meetings at April IETF In-Reply-To: <199703231721.JAA20425@valathar.eng.sun.com> Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I received word today that the AVT schedule for the Memphis meeting has been changed. Our time is now all on Wednesday, which is the day chopped into shorter 1-hour slots. We have three assigned: Wednesday Morning I (9:00-10:00) Wednesday Evening I and Evening II (contiguous, 20:00-22:00) This is one hour less than we have had for recent meetings, but it seems that we may need less time at this meeting. I received a few requests for agenda items (MIB, H.263, MPEG); are there others? There has not been as much activity since the last meeting as I anticipated, especially with regard to specification of additional profiles for other RTCP scenarios. It may be that some of the more complicated ideas have fatal problems or simply require more time to develop -- more research than engineering. Bernard Aboba responded with a suggestion that perhaps the only new profile we need is one that allows the RTCP bandwidth fraction to be specified, and my response was to wonder where that parameter would be signalled. Based on a recent conversation with Mark Handley, I think that instead of defining a new profile, perhaps all we need is to change the current profile to establish 5% as the default, but to allow the fraction to be specified as a session parameter. For example, in SDP where there is now a "session bandwidth" attribute, we could define an additional, separate attribute to specify the RTCP bandwidth. In fact, because one may want to reduce the bandwidth for reception reports to zero, but one would usually still want sender reports to establish the CNAME and provide synchronization timestamps, Mark suggested an attribute with two paramaters: one giving the RTCP bandwidth for data senders, and a second giving the RTCP bandwidth for receivers. (Currently, senders get at least 1/4 of the 5% BW). This would cover the applications Bernard wanted (some with a low feedback BW fraction, and some with none at all). For sessions that might adapt the coding over a large BW range, this separate attribute would also allow specifying an RTCP BW corresponding to a nominal session BW that might be significantly below the max BW given by the existing attribute for the overall session BW. Beyond this, I think the outcome of the discussion at the last meeting is that "timer reconsideration" should be added to the interval calculation algorithm to manage simultaneous joins. I also believe the current fixed minimum interval value of 5 seconds and corresponding initial interval value of 2.5 seconds should be scaled with the RTCP bandwidth so that there is enough time for timer reconsideration to work on low bandwidth lines. These things would just be edits to the RTP spec before Draft Standard. Do others agree with this summary of where we are? Are there issues to be discussed (though let's not simply repeat the discussion from last time, please)? Other new ideas? -- Steve From rem-conf-request@es.net Tue Mar 25 02:54:17 1997 Received: from darlington.darlington.com by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Mar 1997 23:53:34 -0800 Received: from immerman.darlington.com (dialin-1.darlington.com [205.177.46.31]) by darlington.darlington.com (8.6.12/8.6.12) with SMTP id CAA05636 for ; Tue, 25 Mar 1997 02:53:29 -0500 Message-Id: <2.2.32.19970325075326.00686fa8@darlington.com> X-Sender: immerman@darlington.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Mar 1997 02:53:26 -0500 To: rem-conf@es.net From: Bill Immerman Subject: subscribe Please subscribe me From rem-conf-request@es.net Tue Mar 25 03:21:58 1997 Received: from hofmann.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 00:20:48 -0800 Received: from internaut.com (internaut.com [204.57.137.2]) by hofmann.CS.Berkeley.EDU (8.6.11/8.6.6.Beta11) with SMTP id AAA07424; Tue, 25 Mar 1997 00:20:44 -0800 Received: from [204.57.137.9] by internaut.com (NX5.67c/NeXT-3.0) id AA19471; Tue, 25 Mar 97 00:09:19 -0800 Received: by multi with Microsoft Mail id <01BC38B1.D9EBB000@multi>; Tue, 25 Mar 1997 00:16:57 -0800 Message-Id: <01BC38B1.D9EBB000@multi> From: Bernard Aboba To: "Michael F. Speer" , 'Stephen Casner' Cc: "rem-conf@es.net" Subject: RE: AVT meetings at April IETF Date: Tue, 25 Mar 1997 00:16:56 -0800 Encoding: 7 TEXT The idea of separate attributes for sender and receiver report bandwidths is a good one. Question: will this bandwidth be specified as an absolute number, or as a fraction of 5 percent? The fraction might be better security-wise so that someone could not increase the bandwidth unreasonably. From rem-conf-request@es.net Tue Mar 25 03:26:28 1997 Received: from RUTGERS.EDU by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 00:25:37 -0800 Received: from faui40.informatik.uni-erlangen.de (root@faui40.informatik.uni-erlangen.de [131.188.2.40]) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) with ESMTP id DAA20696 for ; Tue, 25 Mar 1997 03:25:33 -0500 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by faui40.informatik.uni-erlangen.de (8.8.5/8.0.5-FAU) with ESMTP id JAA07680; Tue, 25 Mar 1997 09:25:31 +0100 (MET) From: Toerless Eckert Message-Id: <199703250825.JAA07680@faui40.informatik.uni-erlangen.de> Subject: Re: Video Format To: vinay@agni.nuko.com (Vinay Bannai) Date: Tue, 25 Mar 1997 09:25:30 +0100 (MET) Cc: sjn@walsin.com.my, ru-comp-dev-ietf-rem-conf@rutgers.edu In-Reply-To: <199703241751.JAA28798@agni.nuko.com> from "Vinay Bannai" at Mar 24, 97 09:51:21 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > CIF stands for Common Intermediate Format (CIF). This a just a video > source input format. There are others too, like SIF and CCIR601. For > example, if you are using CIF video input, typically it means you are > using 352x288 resolution. It has nothing to do with compression and is not > the compression file. Well, i think that CIF does too imply to have non-square-pixel resolution, i.e.: a CIF-picture is supposed to transport a video picture that has a square-pixel resolution of 375x288. This is often not done correctly (i.e.: i think vic and a lot of other videoconferencing applications actually transport square pixel-video-content in the 352x288 resolution). From rem-conf-request@es.net Tue Mar 25 07:56:52 1997 Received: from ebene.inrialpes.fr by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 04:55:50 -0800 Received: from guadalupe.inrialpes.fr (guadalupe.inrialpes.fr [194.199.20.37]) by ebene.inrialpes.fr (8.6.13-durand/8.6.9) with ESMTP id NAA05931 for ; Tue, 25 Mar 1997 13:55:34 +0100 Received: from guadalupe.inrialpes.fr (localhost [127.0.0.1]) by guadalupe.inrialpes.fr (8.8.3/8.6.9) with ESMTP id NAA17221; Tue, 25 Mar 1997 13:55:34 +0100 (MET) Message-Id: <199703251255.NAA17221@guadalupe.inrialpes.fr> To: rem-conf@es.net cc: Claude.Castelluccia@imag.fr Subject: Question about IPMulticast! Date: Tue, 25 Mar 1997 13:55:33 +0100 From: Claude Castelluccia When a host joins a multicast group, it takes some time before this host starts receiving data from this group? How long does it really take? Are they studies that evaluate or measure this time? Thanks. Claude. From rem-conf-request@es.net Tue Mar 25 09:14:52 1997 Received: from burdell.cc.gatech.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 06:14:21 -0800 Received: from flora.cc.gatech.edu (kevin@flora.cc.gatech.edu [130.207.8.20]) by burdell.cc.gatech.edu (8.8.4/8.6.9) with ESMTP id JAA04241; Tue, 25 Mar 1997 09:14:13 -0500 (EST) Received: (from kevin@localhost) by flora.cc.gatech.edu (8.8.4/8.6.9) id JAA10541; Tue, 25 Mar 1997 09:14:12 -0500 (EST) Date: Tue, 25 Mar 1997 09:14:12 -0500 (EST) From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199703251414.JAA10541@flora.cc.gatech.edu> To: rem-conf@es.net Subject: Re: 7-11 April is going to be tight on the MBONE Cc: rodgers@nlm.nih.gov >>The announcement from Kobe indicates that there will be at least four >>conferences of international scope contending for MBONE bandwidth during >>the week of 7-11 April. WWW6 and CHEP '97 have announced to this group >>many weeks ago and are actively advertising at the moment via sd/sdr. >>1) Scheduling and priorities. This is a BIG can of worms. I suggest we consider all four to be equally important. Is anything else really an option? * Trying to have a discussion of which is more important is going to be useless and among other things, how do you enforce it? Telling Infocom not to broadcast is a bit laughable. * Using when an advertisement was made as a scheduling priority isn't going to work. Ever play the who-gets-the-front-seat-in-the-car game? After a while you start having to make rules about how far in advance you are going to allow reservations, etc. My suggestion is if you/we REALLY want to do any limiting then start up a whiteboard session and have a discussion about what times will be needed to broadcast live. As Mark suggested, the time zones should help a lot. I also think re-broadcasts should be delayed until some time later. -------------------- Cut here to ignore personal plug -------------------- Actually, what about making the sessions available via the IMJ? :-) (That's http://imj.gatech.edu for those who haven't seen/heard.) This would work especially well for the IETF sessions since they could be chopped into per-agenda-item pieces. For conferences you could do per-speaker segments. We've thought about doing this in the past but some of the IETF sessions seemed pretty dry especially compared to Bugs! But there certainly could an actual need. I'm pretty sure Evi still tapes the sessions and these could be encoded and put on the IMJ. -Kevin Almeroth From rem-conf-request@es.net Tue Mar 25 09:34:00 1997 Received: from giane.cs.umass.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 06:33:20 -0800 Received: (from kasera@localhost) by giane.cs.umass.edu (8.7.6/8.7.3) id JAA08513; Tue, 25 Mar 1997 09:31:06 -0500 From: Sneha Kumar Kasera Message-Id: <199703251431.JAA08513@giane.cs.umass.edu> Subject: Re: Question about IPMulticast! To: Claude.Castelluccia@imag.fr (Claude Castelluccia) Date: Tue, 25 Mar 1997 09:31:05 -0500 (EST) Cc: rem-conf@es.net, Claude.Castelluccia@imag.fr In-Reply-To: <199703251255.NAA17221@guadalupe.inrialpes.fr> from "Claude Castelluccia" at Mar 25, 97 01:55:33 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit You could look at "Performance and Resource Cost Comparisons for the CBT and PIM Multicast Routing Protocols in DIS Environments" by T.Billhartz and others. I think this paper appeared in Infocom 1996. Sneha > > > When a host joins a multicast group, it takes some time > before this host starts receiving data from this group? > How long does it really take? Are they studies > that evaluate or measure this time? > > Thanks. > > Claude. > From rem-conf-request@es.net Tue Mar 25 10:25:32 1997 Received: from cheerios.cisco.com by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 07:24:40 -0800 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id HAA11539; Tue, 25 Mar 1997 07:23:59 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <199703251255.NAA17221@guadalupe.inrialpes.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Mar 1997 07:23:36 -0800 To: Claude Castelluccia From: Steve Deering Subject: Re: Question about IPMulticast! Cc: rem-conf@es.net, Claude.Castelluccia@imag.fr At 4:55 AM -0800 3/25/97, Claude Castelluccia wrote: > When a host joins a multicast group, it takes some time > before this host starts receiving data from this group? > How long does it really take? Are they studies > that evaluate or measure this time? For shortest-path-style multicast routing protocols like DVMRP or MOSPF, the worst case delay is roughly the round-trip time from the receiver to the sender. For shared-tree-style protocols like PIM-SM and CBT, worst case is the RTT from receiver to RP/core, plus RTT from RP/core to source. Those are the worst case; it is often better than that, i.e., the RTT >from the receiver to the nearest point on the existing multicast delivery tree. That's the theory; I am not aware of any measurement results that show that reality matches theory. Steve From rem-conf-request@es.net Tue Mar 25 12:07:39 1997 Received: from ebene.inrialpes.fr by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 09:06:08 -0800 Received: from guadalupe.inrialpes.fr (guadalupe.inrialpes.fr [194.199.20.37]) by ebene.inrialpes.fr (8.6.13-durand/8.6.9) with ESMTP id SAA07559; Tue, 25 Mar 1997 18:06:03 +0100 Received: from guadalupe.inrialpes.fr (localhost [127.0.0.1]) by guadalupe.inrialpes.fr (8.8.3/8.6.9) with ESMTP id SAA17937; Tue, 25 Mar 1997 18:06:03 +0100 (MET) Message-Id: <199703251706.SAA17937@guadalupe.inrialpes.fr> To: Steve Deering cc: Claude.Castelluccia@imag.fr, rem-conf@es.net Subject: Re: Question about IPMulticast! In-reply-to: Your message of "Tue, 25 Mar 1997 07:23:36 PST." Date: Tue, 25 Mar 1997 18:06:03 +0100 From: Claude Castelluccia >For shortest-path-style multicast routing protocols like DVMRP or MOSPF, >the worst case delay is roughly the round-trip time from the receiver to >the sender. For shared-tree-style protocols like PIM-SM and CBT, worst >case is the RTT from receiver to RP/core, plus RTT from RP/core to source. >Those are the worst case; it is often better than that, i.e., the RTT >from the receiver to the nearest point on the existing multicast delivery >tree. That's the theory; I am not aware of any measurement results that >show that reality matches theory. Thanks for your answer, but I think that 2 additional componants should be added to your estimation: t1- When a host wants to join a group, it musts wait for the next Query sent by the Designated Router. This might take t1. t2- Then if this mulicast router is not part of the tree, its must wait until the pruned branches grow back. This might take t2. t1 could be minimized by having hosts sending join queries to their designated router instead of waiting for the router's query. t2 could be minimized by having designated routers sending messages to the mrouters toward the source to make the pruned branches grow back faster. Do those options exist? Are implemented and used? Am I missing something? Thanks a lot! Claude. From rem-conf-request@es.net Tue Mar 25 12:35:02 1997 Received: from cheerios.cisco.com by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 09:34:14 -0800 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id JAA18827; Tue, 25 Mar 1997 09:33:37 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <199703251706.SAA17937@guadalupe.inrialpes.fr> References: Your message of "Tue, 25 Mar 1997 07:23:36 PST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Mar 1997 09:33:13 -0800 To: Claude Castelluccia From: Steve Deering Subject: Re: Question about IPMulticast! Cc: Claude.Castelluccia@imag.fr, rem-conf@es.net At 9:06 AM -0800 3/25/97, Claude Castelluccia wrote: > Thanks for your answer, but I think that 2 additional componants should >be added > to your estimation: > > t1- When a host wants to join a group, it musts wait for the next Query > sent by the Designated Router. This might take t1. That is incorrect. When a host first joins a group, it immediately sends a couple of IGMP Reports for that group; it does not wait for the next IGMP Query. > t2- Then if this mulicast router is not part of the tree, its must wait > until the pruned branches grow back. This might take t2. That is also incorrect (and a widely-held misconception, it seems). With both DVMRP and PIM-DM, when a member of a new group appears on a subnet that has previously been pruned for that group, the router(s) on that subnet immediately send "graft" messages to undo the pruning. So, yes, both of the options that you suggested for reducing join latency have always been part of the multicast routing machinery. Thus my original answer to you: the join latency is at worst the RTT from receiver to source (ignoring the hop-by-hop processing delays, which are negligible on paths of any significant distance). Steve From rem-conf-request@es.net Tue Mar 25 12:48:12 1997 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 09:47:26 -0800 Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id JAA18994; Tue, 25 Mar 1997 09:46:44 -0800 (PST) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.6/8.7.3) id JAA08064; Tue, 25 Mar 1997 09:46:54 -0800 (PST) Original-Received: by ccm.jf.intel.com (ccmgate 3.2 #6) Tue, 25 Mar 97 09:46:53 PST PP-warning: Illegal Received field on preceding line Date: Tue, 25 Mar 97 09:45:00 PST From: John Du Message-ID: To: rem-conf-request@es.net, deering@cisco.com cc: Claude.Castelluccia@imag.fr, rem-conf@es.net Subject: Re[2]: Question about IPMulticast! Text item: >For shortest-path-style multicast routing protocols like DVMRP or MOSPF, >the worst case delay is roughly the round-trip time from the receiver to >the sender. For shared-tree-style protocols like PIM-SM and CBT, worst >case is the RTT from receiver to RP/core, plus RTT from RP/core to source. >Those are the worst case; it is often better than that, i.e., the RTT >from the receiver to the nearest point on the existing multicast delivery >tree. That's the theory; I am not aware of any measurement results that >show that reality matches theory. Thanks for your answer, but I think that 2 additional componants should be added to your estimation: t1- When a host wants to join a group, it musts wait for the next Query sent by the Designated Router. This might take t1. t2- Then if this mulicast router is not part of the tree, its must wait until the pruned branches grow back. This might take t2. t1 could be minimized by having hosts sending join queries to their designated router instead of waiting for the router's query. t2 could be minimized by having designated routers sending messages to the mrouters toward the source to make the pruned branches grow back faster. Do those options exist? Yes. For DVMRP, if this mulicast router is not part of the tree, it will send a GRAFT to its upstream neighbor. So t2 is not necessary. Are implemented and used? Am I missing something? Thanks a lot! Claude. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. From: Claude Castelluccia Date: Tue, 25 Mar 1997 18:06:03 +0100 In-reply-to: Your message of "Tue, 25 Mar 1997 07:23:36 PST." Subject: Re: Question about IPMulticast! cc: Claude.Castelluccia@imag.fr, rem-conf@es.net To: Steve Deering Message-Id: <199703251706.SAA17937@guadalupe.inrialpes.fr> Received: from guadalupe.inrialpes.fr (localhost [127.0.0.1]) by guadalupe.inrialpes.fr (8.8.3/8.6.9) with ESMTP id SAA17937; Tue, 25 Mar 1997 18:06:03 +0100 (MET) Received: from guadalupe.inrialpes.fr (guadalupe.inrialpes.fr [194.199.20.37]) by ebene.inrialpes.fr (8.6.13-durand/8.6.9) with ESMTP id SAA07559; Tue, 25 Mar 1997 18:06:03 +0100 Received: from ebene.inrialpes.fr by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 09:06:08 -0800 Received: from osi-west.es.net (osi-west.es.net [198.128.3.61]) by ormail.intel.com (8.8.4/8.8.4) with SMTP id JAA14133; Tue, 25 Mar 1997 09:24:51 -0800 (PST) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i ntel.com (8.7.6/8.7.3) with ESMTP id JAA04247; Tue, 25 Mar 1997 09:25:20 -0800 ( PST) Return-Path: rem-conf-request@es.net From rem-conf-request@es.net Tue Mar 25 13:03:06 1997 Received: from FNAL.FNAL.Gov by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 10:01:39 -0800 Received: from gungnir.fnal.gov ("port 32850"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IGX35PR0VU000RKN@FNAL.FNAL.GOV>; Tue, 25 Mar 1997 12:01:13 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id MAA01187; Tue, 25 Mar 1997 12:01:09 -0600 Date: Tue, 25 Mar 1997 12:01:09 -0600 From: Matt Crawford Subject: Re: Question about IPMulticast! In-reply-to: "25 Mar 1997 18:06:03 +0100." <"199703251706.SAA17937"@guadalupe.inrialpes.fr> Sender: crawdad@gungnir.fnal.gov To: Claude Castelluccia Cc: rem-conf@es.net Message-id: <199703251801.MAA01187@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Thanks for your answer, but I think that 2 additional componants > should be added to your estimation: > > t1- When a host wants to join a group, it musts wait for the next Query > sent by the Designated Router. This might take t1. No. Read RFC1112, the middle of page 13: When a host joins a new group, it should immediately transmit a Report for that group, rather than waiting for a Query, in case it is the first member of that group on the network. To cover the possibility of the initial Report being lost or damaged, it is recommended that it be repeated once or twice after short delays. > t2- Then if this mulicast router is not part of the tree, its must > wait until the pruned branches grow back. This might take t2. No. The mechanism to avoid this delay depends on the multicast routing protocol, but I think every such protocol includes such a mechanism. > Am I missing something? Umm, access to the protocol specs? From rem-conf-request@es.net Tue Mar 25 13:07:11 1997 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 10:06:30 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16303(7)>; Tue, 25 Mar 1997 10:06:17 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177486>; Tue, 25 Mar 1997 10:06:08 -0800 To: Steve Deering cc: Claude Castelluccia , rem-conf@es.net Subject: Re: Question about IPMulticast! In-reply-to: Your message of "Tue, 25 Mar 97 09:33:13 PST." Date: Tue, 25 Mar 1997 10:06:07 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <97Mar25.100608pst.177486@crevenia.parc.xerox.com> Steve Deering wrote: >At 9:06 AM -0800 3/25/97, Claude Castelluccia wrote: >> t2- Then if this mulicast router is not part of the tree, its must wait >> until the pruned branches grow back. This might take t2. > >That is also incorrect (and a widely-held misconception, it seems). Not surprising; it's in Cisco's documentation. Cisco's web site has lots of half-truths (or less) about DVMRP. Bill From rem-conf-request@es.net Tue Mar 25 13:13:19 1997 Received: from cs.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 10:11:49 -0800 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id NAA22621; Tue, 25 Mar 1997 13:11:46 -0500 (EST) Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id NAA09427; Tue, 25 Mar 1997 13:11:44 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <33381560.7ACC@cs.columbia.edu> Date: Tue, 25 Mar 1997 13:11:44 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: "Kevin C. Almeroth" CC: rem-conf@es.net, rodgers@nlm.nih.gov Subject: Re: 7-11 April is going to be tight on the MBONE References: <199703251414.JAA10541@flora.cc.gatech.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit FCFS priority also doesn't work since some events schedule/advertise Mbone transmissions only after most of the registration period is over, in the (possibly misguided) belief that they don't want the freebie Mbone to cannibalize the paying attendance base. From rem-conf-request@es.net Tue Mar 25 13:47:51 1997 Received: from stilton.cisco.com by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 10:44:36 -0800 Received: (dino@localhost) by stilton.cisco.com (8.6.12/8.6.5) id KAA14481; Tue, 25 Mar 1997 10:44:30 -0800 Date: Tue, 25 Mar 1997 10:44:30 -0800 From: Dino Farinacci Message-Id: <199703251844.KAA14481@stilton.cisco.com> To: fenner@parc.xerox.com CC: deering@cisco.com, Claude.Castelluccia@imag.fr, rem-conf@es.net In-reply-to: <97Mar25.100608pst.177486@crevenia.parc.xerox.com> (message from Bill Fenner on Tue, 25 Mar 1997 10:06:07 PST) Subject: Re: Question about IPMulticast! >> Not surprising; it's in Cisco's documentation. Cisco's web site has lots >> of half-truths (or less) about DVMRP. This is not the case on the engineering web page. Bill, tell me where this bug is and I'll get it fixed. Dino From rem-conf-request@es.net Tue Mar 25 13:51:02 1997 Received: from giane.cs.umass.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 10:45:19 -0800 Received: (from kasera@localhost) by giane.cs.umass.edu (8.7.6/8.7.3) id NAA11341; Tue, 25 Mar 1997 13:45:01 -0500 From: Sneha Kumar Kasera Message-Id: <199703251845.NAA11341@giane.cs.umass.edu> Subject: Re: Question about IPMulticast! To: deering@cisco.com (Steve Deering) Date: Tue, 25 Mar 1997 13:45:00 -0500 (EST) Cc: Claude.Castelluccia@imag.fr, rem-conf@es.net In-Reply-To: from "Steve Deering" at Mar 25, 97 09:33:13 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > That is incorrect. When a host first joins a group, it immediately sends > a couple of IGMP Reports for that group; it does not wait for the next > IGMP Query. > > > t2- Then if this mulicast router is not part of the tree, its must wait > > until the pruned branches grow back. This might take t2. > > That is also incorrect (and a widely-held misconception, it seems). With > both DVMRP and PIM-DM, when a member of a new group appears on a subnet > that has previously been pruned for that group, the router(s) on that > subnet immediately send "graft" messages to undo the pruning. > > So, yes, both of the options that you suggested for reducing join latency > have always been part of the multicast routing machinery. Thus my original > answer to you: the join latency is at worst the RTT from receiver to source > (ignoring the hop-by-hop processing delays, which are negligible on paths > of any significant distance). > > Steve > I think that join latency could be more than RTT depending upon the processing load at an intermediate hop unless join messages are treated with high priority. As it needs to be received at each hop, a join message has to go through additional "CPU" queueing (different from the fast H/W queues) at each hop. One could ignore the processing delay which is of the order of a few milliseconds but not ignore the additional queueing delays. The difference between "join latency" and RTT is likely to increase with increasing number of hops. I had once conducted RTT experiments where packets were sent with IP options and without IP options. The packets with IP options usually had a much higher RTT(with more fluctuation) in comparison to packets without IP options. I understand that the processing of join messages is different from the processing of packets with IP options. Don't you think we could still get an estimate of the delay due to the "additional" queueing that takes place at the hops ? Sneha > > From rem-conf-request@es.net Tue Mar 25 14:01:10 1997 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 10:58:13 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15907(1)>; Tue, 25 Mar 1997 10:57:04 PST Received: by crevenia.parc.xerox.com id <177486>; Tue, 25 Mar 1997 10:56:38 -0800 From: Bill Fenner To: dino@cisco.com, fenner@parc.xerox.com Subject: Re: Question about IPMulticast! Cc: Claude.Castelluccia@imag.fr, deering@cisco.com, rem-conf@es.net Message-Id: <97Mar25.105638pst.177486@crevenia.parc.xerox.com> Date: Tue, 25 Mar 1997 10:56:27 PST Well, typing "DVMRP" in the search engine on cio.cisco.com brings up at least 2 documents with errors, and searching at http://cio.cisco.com/univercd/home/search.htm brings up more. A quick survey shows http://cio.cisco.com/warp/public/732/IP/cgmp_wp.htm http://cio.cisco.com/warp/public/543/21.html http://cio.cisco.com/warp/public/614/17.html http://www.cisco.com/univ-src/ccden/data/doc/cintrnet/idg3/idgmulti.htm but I don't really have time to go through all the documents on Cisco's web site. Given that I found the above in 5 minutes I bet a wider search could find more. Bill From rem-conf-request@es.net Tue Mar 25 14:34:13 1997 Received: from cheerios.cisco.com by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 11:30:37 -0800 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id LAA27051; Tue, 25 Mar 1997 11:30:22 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <199703251845.NAA11341@giane.cs.umass.edu> References: from "Steve Deering" at Mar 25, 97 09:33:13 am Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Mar 1997 11:29:56 -0800 To: Sneha Kumar Kasera From: Steve Deering Subject: Re: Question about IPMulticast! Cc: rem-conf@es.net > I think that join latency could be more than RTT depending upon the >processing > load at an intermediate hop unless join messages are treated with high > priority. That's why I said in my first reply that that join latency is "roughly" the RTT, which based on the nature of the original question is close enough to the right answer. The questioner was apparently concerned that the latencies would be on the order of many seconds, like the IGMP query interval or DVMRP prune lifetime. In fact the latencies should be on the order of the RTT (perhaps some smallish multiple), not on the order of 10s of seconds or minutes. (It's also why I said "in theory", because you are right that there might be some pathologically bad behavior observable in the field.) Steve From rem-conf-request@es.net Tue Mar 25 14:54:31 1997 Received: from faui40.informatik.uni-erlangen.de by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 11:45:58 -0800 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by faui40.informatik.uni-erlangen.de (8.8.5/8.0.5-FAU) with ESMTP id UAA25564; Tue, 25 Mar 1997 20:45:55 +0100 (MET) From: Toerless Eckert Message-Id: <199703251945.UAA25564@faui40.informatik.uni-erlangen.de> Subject: Re: Question about IPMulticast! To: dino@cisco.com (Dino Farinacci) Date: Tue, 25 Mar 1997 20:45:52 +0100 (MET) Cc: fenner@parc.xerox.com, deering@cisco.com, Claude.Castelluccia@imag.fr, rem-conf@es.net In-Reply-To: <199703251844.KAA14481@stilton.cisco.com> from "Dino Farinacci" at Mar 25, 97 10:44:30 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit >> Not surprising; it's in Cisco's documentation. Cisco's web site has lots >> of half-truths (or less) about DVMRP. What's the shortest half-truth ? "Cisco Does DVMRP" (do not confuse with: "Debbie Does Dallas") Sorry, couldn't resist ;-))))) From rem-conf-request@es.net Tue Mar 25 14:55:56 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 11:46:58 -0800 Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id LAA00890; Tue, 25 Mar 1997 11:26:09 -0800 Date: Tue, 25 Mar 1997 11:28:02 -0800 () From: Stephen Casner To: Bernard Aboba cc: "rem-conf@es.net" Subject: Specifying RTCP BW (was: AVT meetings at April IETF) In-Reply-To: <01BC38B1.D9EBB000@multi> Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > The idea of separate attributes for sender and receiver report bandwidths > is a good one. > > Question: will this bandwidth be specified as an absolute number, or as > a fraction of 5 percent? The fraction might be better security-wise so that > someone could not increase the bandwidth unreasonably. There are many different ways we could do this, and I think any of them could be abused. What is to keep someone from specifying a fraction greater than 1? Also, there may be applications where more than 5% is appropriate. I think be best guideline is a choice that minimizes the likelihood of confusion. In separate email, Mark Handley proposed: We have two choices for how to implement this - a bandwidth field or an attribute. Given that this is RTP-specific, and that this is relative to a bandwidth field, I'd probably favour an attribute. Perhaps: a=rtcpbw:5 1.25 Where the first number is the total proportion of session bandwidth to be used by RTCP (RR+SRs) and the second is the minimum proportion of the session b/w to be used by RTCP SRs. Both numbers are percentages (seems more compact than fractions of the b/w). If the two numbers are the same, no b/w is used by RRs. This keeps the numbers the same as two numbers that currently appear in the interval calculation algorithm. It seems like a reasonable choice to me. -- Steve From rem-conf-request@es.net Tue Mar 25 14:56:53 1997 Received: from toltec.fafb.af.mil by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 11:43:01 -0800 Received: by toltec.fafb.af.mil; id AA20392; Tue, 25 Mar 97 12:46:19 MST Received: from unknown(128.202.65.50) by toltec.fafb.af.mil via smap (V3.1) id xma020372; Tue, 25 Mar 97 12:46:03 -0700 Received: from AFMCFAFB.FAFB.AF.MIL ([128.202.65.32]) by newton.fafb.af.mil with SMTP (1.37.109.16/16.2) id AA083849317; Tue, 25 Mar 1997 12:48:37 -0700 Received: by AFMCFAFB.FAFB.AF.MIL with Microsoft Mail id <3337C877@AFMCFAFB.FAFB.AF.MIL>; Tue, 25 Mar 97 12:43:35 MST From: "Balanesi, Terry H., Cntr." To: 'AVT Working Group' Subject: FW: IP Multicasting Date: Tue, 25 Mar 97 12:43:00 MST Message-Id: <3337C877@AFMCFAFB.FAFB.AF.MIL> Encoding: 23 TEXT X-Mailer: Microsoft Mail V3.0 ---------- From: Steve Coya To: Balanesi, Terry H., Cntr. Subject: Re: IP Multicasting Date: Monday, March 24, 1997 4:23PM Terry, Sorry for the previous message - wrong envelope! >> I am hoping you can direct me to someone who understands IP multicating >> and the relationship to this type of route addressing and TCP. I would >> appreciate any help you can give me. You might start off by sending a message to the AVT Working Group. They may be able to vector you to the right resource. The email address is rem-conf@es.net From rem-conf-request@es.net Tue Mar 25 15:01:02 1997 Received: from hofmann.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 11:53:08 -0800 Received: from internaut.com (internaut.com [204.57.137.2]) by hofmann.CS.Berkeley.EDU (8.6.11/8.6.6.Beta11) with SMTP id LAA13838; Tue, 25 Mar 1997 11:52:36 -0800 Received: by internaut.com (NX5.67c/NeXT-3.0) id AA21448; Tue, 25 Mar 97 11:41:09 -0800 Date: Tue, 25 Mar 1997 11:41:09 -0800 (GMT-0800) From: "Bernard D. Aboba" To: Stephen Casner Cc: "rem-conf@es.net" Subject: Re: Specifying RTCP BW (was: AVT meetings at April IETF) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Including the percentages is ok, but isn't it desirable to put some upper limit on this? Is there a compelling reason for why RTCP bandwidth might go above 30 percent of the total? From rem-conf-request@es.net Tue Mar 25 15:10:30 1997 Received: from emout07.mail.aol.com (actually emout07.mx.aol.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 12:04:08 -0800 Received: (from root@localhost) by emout07.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0) id PAA05094 for rem-conf@es.net; Tue, 25 Mar 1997 15:04:04 -0500 (EST) Date: Tue, 25 Mar 1997 15:04:04 -0500 (EST) From: VMatthies@aol.com Message-ID: <970325150402_47197323@emout07.mail.aol.com> To: rem-conf@es.net Subject: unsubsribe unsubscribe From rem-conf-request@es.net Tue Mar 25 15:16:34 1997 Received: from silver.sms.fi by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 12:05:23 -0800 Received: from OmniP (silver.sms.fi [194.111.122.17]) by silver.sms.fi (8.8.5/8.7.3) with SMTP id WAA21807; Tue, 25 Mar 1997 22:04:08 +0200 (EET) Date: Tue, 25 Mar 1997 22:04:08 +0200 (EET) Message-Id: <199703252004.WAA21807@silver.sms.fi> X-Sender: pete@127.0.0.1 X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rodgers@nlm.nih.gov (R. P. C. Rodgers), rem-conf@es.net, mbone@ISI.EDU From: Petri Helenius Subject: Re: 7-11 April is going to be tight on the MBONE (Was: Broadcasting of Infocom'97) Cc: infocom411@ckp.or.jp, oka@kobe-u.ac.jp, dem@hep.net, likavec@igd.fhg.de At 14:43 24.3.1997 -0500, R. P. C. Rodgers wrote: > If we have many more weeks like 7-11 April, are we going to have to > get more serious about enforcing some rules of priority, based on > advanced reservations, and perhaps some discussion of relative > priorities? I'd hate to get into this business, but will it be > necessary? No, we just need to push the available bandwidth higher since in my opinion MBone is much more effective use of it than most of the unicast replication based apps. I also value the conferences highly. I would like the transmitters to monitor the incoming RTCP packets and spot bad links while the transmission is active. It might also be a good idea to try something at these levels of bandwidth a week or two advance to the actual sessions to see how the network would behave. > Pete From rem-conf-request@es.net Tue Mar 25 15:57:14 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 12:48:39 -0800 Received: from big-bear by precept.com (SMI-8.6/SMI-SVR4) id MAA01223; Tue, 25 Mar 1997 12:41:52 -0800 Date: Tue, 25 Mar 1997 12:41:52 -0800 (PST) From: Karl Auerbach X-Sender: karl@big-bear Reply-To: karl@precept.com To: Claude Castelluccia cc: rem-conf@es.net Subject: Re: Question about IPMulticast! In-Reply-To: <199703251255.NAA17221@guadalupe.inrialpes.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > When a host joins a multicast group, it takes some time > before this host starts receiving data from this group? > How long does it really take? Are they studies > that evaluate or measure this time? I've been doing some very unscientific measurements of this... On an extremely well endowed network (underloaded ATM underpinnings, mongo IP routers, not much IP traffic, few (<4) IP hops end-to-end, the whole thing in one big room, etc) I've been observing join latencies (the time between when I send an IGMP Group Membership packet from a host until the time the data on the multicast group arrives) of from nearly nil to perhaps 10 seconds. (I'm guessing about the 10 seconds because it was more of a "where is that traffic?" kind of thing -- like sitting at a traffic light -- in which time streeeeeeetches.) I'm not sure why it sometimes took so long. Since this network was using ATM Forum LAN Emulation (only on the router-to-host paths, not on the inter-router paths), I have this suspicion that some of the time may have been consumed by IGMP sniffing edge devices. But I have no specific evidence to support that. --karl-- From rem-conf-request@es.net Tue Mar 25 16:12:41 1997 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 12:54:03 -0800 Received: from grazie.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 25 Mar 1997 20:51:37 +0000 From: Orion Hodson Reply-To: rat-trap@cs.ucl.ac.uk To: rem-conf@es.net cc: ucl-audio@cs.ucl.ac.uk, merci@cs.ucl.ac.uk, mice-nsc-uk@cs.ucl.ac.uk Subject: New RAT release (v3.0.18) Date: Tue, 25 Mar 1997 20:51:34 +0000 Message-ID: <1554.859323094@cs.ucl.ac.uk> Sender: O.Hodson@cs.ucl.ac.uk The Robust-Audio Tool (RAT) is designed to allow multiple users to talk to each other over the internet. RAT is adaptive to network and host conditions. It is RTP compliant and can be operated in unicast and multicast modes. It is compatible with other Mbone audio tools (VAT, FreePhone, IP/TV) and offers redundant audio encoding and receiver based repair to provide improved sound quality. Further details can be found at http://www-mice.cs.ucl.ac.uk/mice/rat/. Binaries (and man page) are available at the UCL ftp server: ftp://cs.ucl.ac.uk/mice/rat/ and currently exist for Solaris, SunOS, Irix, Linux, HP-UX and Windows95. FreeBSD, and possibly OSF/1, versions will be available shortly. Users of earlier releases should upgrade now to enjoy improved audio quality and stability. This release has the following enhancements, compared to release 2.6: - Improved redundancy support - Improved packet repetition - Transcoder/mixer operation - Flakeway operation - Lecture mode - LBL conference bus compatibility - Audio device trading between multiple instances of rat/vat - Voice switching of video when combined with vic - Better RTCP compliance - L16 (16bit linear, uncompressed) codec - Improved performance of analysis-by-synthesis codecs (GSM/LPC) - New user-interface - Active speaker indication now works - Automatic audio DC bias removal - Selective muting of participants - Assorted bug-fixes A large amount of the code has been re-written to make RAT more flexible and reliable. The major enhancement in this release is the ability to operate as a transcoder. RAT will transcode between two multicast groups, unicast and multicast, and unicast-to-unicast. RAT can transcode between any combination of PCMU, L16, DVI, GSM, LPC and redundant audio, and can add/remove encryption as appropriate. Comments, suggestions, and bug-reports should be sent to rat-trap@cs.ucl.ac.uk. regards Colin, Orion, and Isidor [despite being on a plane to Greece :-) ] From rem-conf-request@es.net Tue Mar 25 17:16:15 1997 Received: from zephyr.isi.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 14:09:14 -0800 Received: from fra-e.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 25 Mar 1997 14:08:56 -0800 Message-Id: <199703252208.AA01720@zephyr.isi.edu> X-Mailer: exmh version 1.6.7 5/3/96 To: Steve Deering Cc: rem-conf@es.net Subject: Re: Question about IPMulticast! In-Reply-To: Your message of "Tue, 25 Mar 1997 09:33:13 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Mar 97 15:10:07 PST From: Daniel Zappala deering@cisco.com said: > So, yes, both of the options that you suggested for reducing join latency > have always been part of the multicast routing machinery. Thus my original > answer to you: the join latency is at worst the RTT from receiver to source > (ignoring the hop-by-hop processing delays, which are negligible on paths > of any significant distance). > Assuming, of course, none of the routing protocol's packets are lost... Daniel Zappala daniel@isi.edu From rem-conf-request@es.net Tue Mar 25 17:44:56 1997 Received: from cheerios.cisco.com by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 14:26:04 -0800 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id OAA08792; Tue, 25 Mar 1997 14:25:55 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <199703252208.AA01720@zephyr.isi.edu> References: Your message of "Tue, 25 Mar 1997 09:33:13 PST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Mar 1997 14:25:31 -0800 To: Daniel Zappala From: Steve Deering Subject: Re: Question about IPMulticast! Cc: rem-conf@es.net At 3:10 PM -0800 3/25/97, Daniel Zappala wrote: > deering@cisco.com said: > > > So, yes, both of the options that you suggested for reducing join latency > > have always been part of the multicast routing machinery. Thus my original > > answer to you: the join latency is at worst the RTT from receiver to source > > (ignoring the hop-by-hop processing delays, which are negligible on paths > > of any significant distance). > > > > Assuming, of course, none of the routing protocol's packets are lost... and that the routing doesn't change during the join, and that the network doesn't partition, and that there are no Byzantine failures in the routers, and that ... What a bunch of picky people we have on this list! Yes, in truth, the worst-case join latency is infinite. Is that a more useful answer? Steve From rem-conf-request@es.net Tue Mar 25 20:29:19 1997 Received: from cogs.gps.com by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 16:15:19 -0800 Received: from [167.220.141.69] by cogs.gps.com (AIX 3.2/UCB 5.64/4.03) id AA21942; Tue, 25 Mar 1997 18:16:13 -0600 Message-Id: <9703260016.AA21942@cogs.gps.com> From: Korey Kirschenmann To: rem-conf Subject: MBONE training sites? Date: Tue, 25 Mar 1997 18:14:31 -0600 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MBONE list, Do any of you know of training centers that have been setup with MBONE access? I am looking for training sites for rent, so I can deliver training to multiple sites at one time utilizing IP multicast and the MBONE technology. Korey Kirschenmann kkirsche@cogs.gps.com 701-281-3183 From rem-conf-request@es.net Tue Mar 25 20:32:05 1997 Received: from postoffice2.mail.cornell.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 17:31:01 -0800 Received: from pclab.gsm.cornell.edu ([128.253.207.104]) by postoffice2.mail.cornell.edu (8.8.5/8.8.5) with SMTP id UAA16047 for ; Tue, 25 Mar 1997 20:30:56 -0500 (EST) Message-Id: <3.0.32.19970325202843.006ed0cc@postoffice3.mail.cornell.edu> X-Sender: eer2@postoffice3.mail.cornell.edu X-Mailer: Windows Eudora Pro Version 3.0 (32) -- [Cornell Modified] Date: Tue, 25 Mar 1997 20:28:44 -0500 To: rem-conf@es.net From: Ethan Rafferty Subject: NFS server research project Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hello, I am an MBA student at Cornell's Johnson School of Management conducting research on NFS servers. My research team would like to send out a conjoint analysis tool (which would take 15 minutes to complete) to potential and actual consumers of NFS servers. The purpose of the study is to analyze consumers' tradeoffs between attributes of the product (such as performance, storage capacity, availability, support of multiple client types, and method of purchase) in order to determine optimal configurations. I would like to discuss with you your suggestions on contacting appropriate individuals, such as systems administrators, to participate in this study. To be more specific, I am seeking lists of contact information for such individuals. Please let me know your suggestions regarding directions in which to proceed. Thanks, Ethan Rafferty (607) 256-1201 eer2@cornell.edu From rem-conf-request@es.net Tue Mar 25 21:20:08 1997 Received: from giane.cs.umass.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 18:18:05 -0800 Received: (from kasera@localhost) by giane.cs.umass.edu (8.7.6/8.7.3) id VAA15535 for rem-conf@es.net; Tue, 25 Mar 1997 21:18:01 -0500 From: Sneha Kumar Kasera Message-Id: <199703260218.VAA15535@giane.cs.umass.edu> Subject: Re: Question about IPMulticast! To: rem-conf@es.net Date: Tue, 25 Mar 1997 21:18:01 -0500 (EST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > So, yes, both of the options that you suggested for reducing join latency > have always been part of the multicast routing machinery. Thus my original > answer to you: the join latency is at worst the RTT from receiver to source > (ignoring the hop-by-hop processing delays, which are negligible on paths > of any significant distance). > > Steve > I think that join latency could be more than RTT depending upon the processing load at an intermediate hop unless join messages are treated with high priority. As it needs to be received at each hop, a join message has to go through additional "CPU" queueing (different from the fast H/W queues) at each hop. One could ignore the processing delay which is of the order of a few milliseconds but not ignore the additional queueing delays. The difference between "join latency" and RTT is likely to increase with increasing number of hops. I had once conducted RTT experiments where packets were sent with IP options and without IP options. The packets with IP options usually had a much higher RTT(with more fluctuation) in comparison to packets without IP options. I understand that the processing of join messages is different from the processing of packets with IP options. Don't you think we could still get an estimate of the delay due to the "additional" queueing that takes place at the hops ? Sneha From rem-conf-request@es.net Tue Mar 25 21:44:09 1997 Received: from ernie.ucop.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Mar 1997 18:40:36 -0800 Received: from local (sfo-ca17-19.ix.netcom.com [205.184.16.179]) by ernie.ucop.edu (8.8.4/8.8.4) with SMTP id SAA33896 for ; Tue, 25 Mar 1997 18:40:21 -0800 Message-Id: <3.0.1.32.19970325183803.0069fdf4@popserv.ucop.edu> X-Sender: pprapuol@popserv.ucop.edu X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 25 Mar 1997 18:38:03 -0800 To: rem-conf@es.net From: "P.G.Prapuolenis" Subject: un Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Can someone tell me how to unsubscribe from this list? From rem-conf-request@es.net Wed Mar 26 04:57:06 1997 Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service id <07929-0@osi-east2.es.net>; Wed, 26 Mar 1997 04:53:50 -0800 Received: from faui40.informatik.uni-erlangen.de by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Mar 1997 04:53:35 -0800 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by faui40.informatik.uni-erlangen.de (8.8.5/8.0.5-FAU) with ESMTP id NAA16720 for ; Wed, 26 Mar 1997 13:53:33 +0100 (MET) From: Toerless Eckert Message-Id: <199703261253.NAA16720@faui40.informatik.uni-erlangen.de> Subject: Wanted: progressive scan video cameras To: rem-conf@es.net Date: Wed, 26 Mar 1997 13:53:31 +0100 (MET) Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi I was wondering If someone could point me to inexpensive progressive-scan color video cameras. I would prefer a camera that delivers NTSC or PAL compatible video signal on output so that it can be transferred into the computer via standard frame-grabbers. I guess something like a SuperNTSC camera would do this trick nicely but i've got no idea where to get those and how expensive they are. I'm also much more interested in a PAL compatible camera. If you know progressive scan cameras that are not PAL/NTSC compatible i'd like to learn which framegrabbers you use with them. The background of the question is that we'd like to go for SCIF (CCIR601) resolution with our research video compression scheme, but that we would like to avoid handling of interlace motion artefact. Best regards Toerless From rem-conf-request@es.net Wed Mar 26 05:47:11 1997 Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service id <08213-0@osi-east2.es.net>; Wed, 26 Mar 1997 05:43:27 -0800 Received: from toltec.fafb.af.mil by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Mar 1997 05:43:13 -0800 Received: by toltec.fafb.af.mil; id AA09932; Wed, 26 Mar 97 06:43:16 MST Received: from unknown(128.202.65.50) by toltec.fafb.af.mil via smap (V3.1) id xma009903; Wed, 26 Mar 97 06:43:03 -0700 Received: from AFMCFAFB.FAFB.AF.MIL ([128.202.65.32]) by newton.fafb.af.mil with SMTP (1.37.109.16/16.2) id AA095453930; Wed, 26 Mar 1997 06:45:30 -0700 Received: by AFMCFAFB.FAFB.AF.MIL with Microsoft Mail id <3338C4D8@AFMCFAFB.FAFB.AF.MIL>; Wed, 26 Mar 97 06:40:24 MST From: "Balanesi, Terry H., Cntr." To: 'AVT Working Group' Subject: FW: Returned mail Date: Wed, 26 Mar 97 06:40:00 MST Message-Id: <3338C4D8@AFMCFAFB.FAFB.AF.MIL> Encoding: 51 TEXT X-Mailer: Microsoft Mail V3.0 ---------- From: BALANESITH To: Balanesi Terry H. Cntr. Subject: Returned mail Date: Tuesday, March 25, 1997 7:49PM ---- message ---- Error transferring to NOTESMAIL1/PICTEL mail.box; Server error: Insufficient disk space Error transferring to NOTESMAIL1/PICTEL mail.box; Server error: Insufficient disk space ---- message ---- Content-Type: Message/rfc822 Content-Description: RFC822 To: 'AVT Working Group' bcc: rem-conf From: "Balanesi Terry H. Cntr." Date: 25 Mar 97 12:43:00 EDT Subject: FW: IP Multicasting MIME-Version: 1.0 Content-Type: Text/Plain ---------- From: Steve Coya To: Balanesi, Terry H., Cntr. Subject: Re: IP Multicasting Date: Monday, March 24, 1997 4:23PM Terry, Sorry for the previous message - wrong envelope! >> I am hoping you can direct me to someone who understands IP multicating >> and the relationship to this type of route addressing and TCP. I would >> appreciate any help you can give me. You might start off by sending a message to the AVT Working Group. They may be able to vector you to the right resource. The email address is rem-conf@es.net ---- message ------ From rem-conf-request@es.net Wed Mar 26 09:03:27 1997 Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service id <09240-0@osi-east2.es.net>; Wed, 26 Mar 1997 09:00:06 -0800 Received: from catarina.usc.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Mar 1997 08:49:29 -0800 Received: from excalibur.usc.edu (excalibur.usc.edu [128.125.51.11]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id XAA10451; Tue, 25 Mar 1997 23:22:29 -0800 Received: (ahelmy@localhost) by excalibur.usc.edu (8.6.10/8.6.9) id XAA10716; Tue, 25 Mar 1997 23:22:28 -0800 Date: Tue, 25 Mar 1997 23:22:28 -0800 (PST) From: Ahmed A-G Helmy To: Daniel Zappala cc: Steve Deering , rem-conf@es.net Subject: Re: Question about IPMulticast! In-Reply-To: <199703252208.AA01720@zephyr.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > deering@cisco.com said: > > > So, yes, both of the options that you suggested for reducing join latency > > have always been part of the multicast routing machinery. Thus my original > > answer to you: the join latency is at worst the RTT from receiver to source > > (ignoring the hop-by-hop processing delays, which are negligible on paths > > of any significant distance). > > > > Assuming, of course, none of the routing protocol's packets are lost... Daniel, I believe that grafts trigger graft acks hbh, and so are more robust to loss of pkts than pure soft state [note that the acks only ameliorate the loss/failure problems but are still susceptible to other node/state failures, and there soft state probably performs better by periodic refreshes]... There is a probabilistic analysis of the join latency for PIM-SM taking packet losses into consideration, as a function of the per link av probability of pkt loss and the domain/network size. This analysis was conducted as part of the bootstrap convergence time estimates found in: http://catarina.usc.edu/pim/pimsm/bootstrap-TechReport.ps.gz or http://www.usc.edu/dept/cs/technical_reports.html TR#: 97-644 Regards, -A > > Daniel Zappala > daniel@isi.edu > > > > From rem-conf-request@es.net Wed Mar 26 12:33:26 1997 Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service id <10623-0@osi-east2.es.net>; Wed, 26 Mar 1997 12:30:06 -0800 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Mar 1997 12:05:38 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16884(5)>; Wed, 26 Mar 1997 12:05:14 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177486>; Wed, 26 Mar 1997 12:05:03 -0800 To: karl@precept.com cc: Claude Castelluccia , rem-conf@es.net Subject: How to test join latency on the MBone (was Re: Question about IPMulticast!) In-reply-to: Your message of "Tue, 25 Mar 97 12:41:52 PST." Date: Wed, 26 Mar 1997 12:04:51 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <97Mar26.120503pst.177486@crevenia.parc.xerox.com> Here's how I would test join latency on the MBone: 1. Find a source and group that is transmitting data. IMJ is a good source if there's nothing else that's transmitting constantly, since you can make it transmit on demand. 2. Mtrace to that source and group and find the closest router that's on the tree. e.g. Mtrace from 130.207.8.30 to 13.2.116.11 via group 224.2.1.2 Querying full reverse path... 0 crevenia (13.2.116.11) -1 tibia-235 (13.2.116.239) DVMRP thresh^ 1 -9 ms Prune sent upstream -2 disco-dart.parc.xerox.com (204.162.228.251) DVMRP thresh^ 0 0 ms Prune sent upstream -3 dodgedart.parc.xerox.com (204.162.228.7) DVMRP thresh^ 1 -85 s Prune sent upstream -4 ames.dart.net (140.173.144.1) DVMRP thresh^ 1 338 ms Prune sent upstream -5 mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 32 48 ms Output pruned -6 sanjose1-mbone1.bbnplanet.net (4.0.0.34) PIM/Special thresh^ 0 356 ms -7 paloalto-mbone1.bbnplanet.net (131.119.0.197) PIM/Special thresh^ 32 411 ms -8 collegepk-mbone1.bbnplanet.net (128.167.252.196) PIM/Special thresh^ 64 399 ms -9 atlanta3-mbone1.bbnplanet.net (192.221.48.234) PIM/Special thresh^ 64 -98 s -10 feta-fddi.gatech.edu (130.207.244.30) DVMRP thresh^ 32 -175 s -11 siwenna.cc.gatech.edu (130.207.9.11) DVMRP thresh^ 8 400 ms -12 ophelia-video.cc.gatech.edu (130.207.10.26) DVMRP thresh^ 1 405 ms -13 muerto.cc.gatech.edu (130.207.8.30) Round trip time 522 ms; total ttl of 69 required. This means that mbone.nsi.nasa.gov is the closest router on the tree, since it says "Output pruned" instead of "Prune sent upstream". The statistics section also shows this: 192.203.230.241 mbone.nsi.nasa.gov Output pruned | ^ ttl 69 120 pps 358/358 =100% 25 pps v | hop -301 ms 192.52.195.128 140.173.144.1 ames.dart.net Prune sent upstream This 100% loss is caused by the prune. 3. Run tcpdump on the group in question 4. Join the group and watch the time between the IGMP join and the first packet. If the join latency is longer than seconds, you can use mtrace as above to find the hop that failed to properly graft. Bill From rem-conf-request@es.net Thu Mar 27 07:02:23 1997 Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service id <19805-0@osi-east2.es.net>; Thu, 27 Mar 1997 06:58:59 -0800 Received: from ietf.org by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Mar 1997 06:58:41 -0800 Received: from ietf.ietf.org by ietf.org id aa17021; 27 Mar 97 9:54 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-mib-00.txt Date: Thu, 27 Mar 1997 09:54:15 -0500 Sender: cclark@ietf.org Message-ID: <9703270954.aa17021@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Real-Time Transport Protocol Management Information Base Author(s) : M. Baugher, J. Du, S. Naudus Filename : draft-ietf-avt-rtp-mib-00.txt Pages : 25 Date : 03/26/1997 This memo defines an experimental Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Real-Time Transport Protocol Systems [1]. Comments should be made to the IETF Audio/Video Transport Working Group. This memo does not specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-mib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-rtp-mib-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-mib-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970326103143.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970326103143.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Thu Mar 27 09:08:42 1997 Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service id <20487-0@osi-east2.es.net>; Thu, 27 Mar 1997 09:05:02 -0800 Received: from arl-img-5.compuserve.com by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Mar 1997 09:04:34 -0800 Received: by arl-img-5.compuserve.com (8.6.10/5.950515) id MAA22179; Thu, 27 Mar 1997 12:04:23 -0500 Date: Thu, 27 Mar 1997 12:03:50 -0500 From: "H. DO-DUY" <106025.3357@compuserve.com> Subject: Building Vat under Windows NT4.0 To: Vat mailing list Message-ID: <199703271203_MC2-135E-F182@compuserve.com> Hi, I'm trying to build Vat 4.0b2 from sources found on the Net, on my Pentium 200 Pro, using NT 4.0 and Visual C++ 4.2. I've got a problem of variable definition that i can't find anywhere. they are declared as extern in two modules, put are never defined, so the link can't be done. Those variables seem to be used to convert mulaw format to linear format : mulawtolin and lintomulaw and lintomulawX Please, tell me, if you can, where i could find the definition of those variables. Thanks a lot Rodolphe PETIT SEEE, Toulouse 28th, march, 97 e-mail : 106025.3357@compuserve.com From rem-conf-request@es.net Thu Mar 27 11:53:36 1997 Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service id <21729-0@osi-east2.es.net>; Thu, 27 Mar 1997 11:50:17 -0800 Received: from mailbag.jf.intel.com by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Mar 1997 11:40:29 -0800 Received: from ideal.jf.intel.com (ideal.jf.intel.com [134.134.130.5]) by mailbag.jf.intel.com (8.8.5/8.7.3) with ESMTP id LAA15735 for ; Thu, 27 Mar 1997 11:42:39 -0800 (PST) Received: from pcrsvp.jf.intel.com (pcrsvp.jf.intel.com [134.134.159.78]) by ideal.jf.intel.com (8.8.5/8.8.4) with SMTP id LAA06902 for ; Thu, 27 Mar 1997 11:37:46 -0800 (PST) Message-Id: <3.0.32.19970327113249.00c0372c@ibeam.intel.com> X-Sender: mbaugher@ibeam.intel.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 27 Mar 1997 11:32:52 -0800 To: rem-conf@es.net From: Mark Baugher Subject: I-D ACTION:draft-ietf-avt-rtp-mib-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" hi, this I-D is a result of some ongoing work we are doing on management of RTP on our network. The MIB definition can be viewed in hypertext format at www.rdrop.com\rtp.mi2. Mark >To: IETF-Announce:; >cc: rem-conf@es.net >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-avt-rtp-mib-00.txt >Date: Thu, 27 Mar 1997 09:54:15 -0500 >Sender: cclark@ietf.org >Content-Length: 3484 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Audio/Video Transport > Working Group of the IETF. > > Title : Real-Time Transport Protocol Management Information Base > Author(s) : M. Baugher, J. Du, S. Naudus > Filename : draft-ietf-avt-rtp-mib-00.txt > Pages : 25 > Date : 03/26/1997 > >This memo defines an experimental Management Information Base (MIB) for >use with network management protocols in TCP/IP-based internets. In >particular, it defines objects for managing Real-Time Transport Protocol >Systems [1]. Comments should be made to the IETF Audio/Video Transport >Working Group. > >This memo does not specify a standard for the Internet community. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-avt-rtp-mib-00.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-avt-rtp-mib-00.txt > >Internet-Drafts directories are located at: > > o Africa: ftp.is.co.za > > o Europe: ftp.nordu.net > ftp.nis.garr.it > > o Pacific Rim: munnari.oz.au > > o US East Coast: ds.internic.net > > o US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-ietf-avt-rtp-mib-00.txt". > >NOTE: The mail server at ds.internic.net can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e., documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version >of the Internet-Draft. > > > From rem-conf-request@es.net Thu Mar 27 17:40:36 1997 Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service id <23539-0@osi-east2.es.net>; Thu, 27 Mar 1997 17:33:23 -0800 Received: from mail-out1.apple.com by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Mar 1997 17:33:17 -0800 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 RAA20696 for ; Thu, 27 Mar 1997 17:31:10 -0800 Received: from mailman.apple.com.CPT (mailman.apple.com [17.206.40.179]) by scv3.apple.com (8.8.5/8.8.4) with SMTP id RAA11258 for ; Thu, 27 Mar 1997 17:34:56 -0800 Received: from [17.255.9.131] (skylawn.research.apple.com) by mailman.apple.com.CPT (4.1/SMI-4.1) id AA27936; Thu, 27 Mar 97 17:33:36 PST Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Mar 1997 17:32:50 -0800 To: rem-conf@es.net From: Alagu Periyannan Subject: RTP over TCP Hi all, Sometime back there was talk about RTP over TCP and maybe even an internet draft. Can anyone provide a pointer to this work? Thanks. Alagu Periyannan alagu@mailman.apple.com Communications Products and Technology Apple Computer, Inc. From rem-conf-request@es.net Fri Mar 28 08:08:03 1997 Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service id <01713-0@osi-east2.es.net>; Fri, 28 Mar 1997 08:04:41 -0800 Received: from burdell.cc.gatech.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 28 Mar 1997 08:04:35 -0800 Received: from flora.cc.gatech.edu (kevin@flora.cc.gatech.edu [130.207.8.20]) by burdell.cc.gatech.edu (8.8.4/8.6.9) with ESMTP id LAA03823; Fri, 28 Mar 1997 11:04:27 -0500 (EST) Received: (from kevin@localhost) by flora.cc.gatech.edu (8.8.4/8.6.9) id LAA17213; Fri, 28 Mar 1997 11:04:26 -0500 (EST) Date: Fri, 28 Mar 1997 11:04:26 -0500 (EST) From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199703281604.LAA17213@flora.cc.gatech.edu> To: rem-conf@es.net Subject: Las Vegas Interop Broadcasts This is to announce our intentions to broadcast parts of the Las Vegas Networld+Interop Show. The broadcast dates are during the day (LV time) >from Monday, May 5th through Thursday, May 8th. I'm not going to say exactly what we are planning to broadcast but it will be content from parts of the General Conference, Intranet Conference, Engineers Conference, and the keynotes. Actually, if you have any interest in making suggestions, you can go to the N+I LV WWW page, take a look at what'll be playing, and send me any preferences or suggestions. The URL is: http://www.interop.com/Interop_Online/htdocs/events/index.html -Kevin Almeroth From rem-conf-request@es.net Fri Mar 28 10:49:46 1997 Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service id <02996-0@osi-east2.es.net>; Fri, 28 Mar 1997 10:43:54 -0800 Received: from ietf.org by osi-west.es.net with ESnet SMTP (PP); Fri, 28 Mar 1997 10:43:37 -0800 Received: from ietf.ietf.org by ietf.org id aa15510; 28 Mar 97 10:13 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-profile-new-00.txt Date: Fri, 28 Mar 1997 10:13:52 -0500 Sender: cclark@ietf.org Message-ID: <9703281013.aa15510@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Profile for Audio and Video Conferences with Minimal Control Author(s) : H. Schulzrinne Filename : draft-ietf-avt-profile-new-00.txt Pages : 26 Date : 03/27/1997 This memo describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. The document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. However, the encoding definitions are independent of the particular transport mechanism used. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-profile-new-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-profile-new-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-profile-new-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970327150436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-profile-new-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-new-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970327150436.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Fri Mar 28 14:31:43 1997 Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service id <04397-0@osi-east2.es.net>; Fri, 28 Mar 1997 14:25:57 -0800 Received: from torsk.hia.no by osi-west.es.net with ESnet SMTP (PP); Fri, 28 Mar 1997 14:25:47 -0800 Received: from flyndre.grm.hia.no by torsk.hia.no with SMTP (PP) id <05037-0@torsk.hia.no>; Fri, 28 Mar 1997 23:24:16 +0000 X-Mailer: exmh version 1.6.2 7/18/95 To: etojs@eto.ericsson.se, ETO.ETOMJEL@memo.ericsson.se, dbworld@cs.wisc.edu, prosoft@iro.umontreal.ca, tccc@cs.umass.edu, end2end-interest@isi.edu, comswtc@gmu.edu, ieeetcpc@ccvm.sunysb.edu, 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, badri@cs.rutgers.edu, hr@zurich.ibm.com, steinara@idt.unit.no, feng@idt.unit.no, pml@eltek.dtu.dk, AlexCh@inconnect.com, fkatz@netcom.com, brodman@tiac.net, NIKULIN@msn.com, tru@kddnews.nes.lab.kdd.co.jp, pmck@kom.auc.dk, dgb@inster.york.ac.uk, Koch@esi.es, davison@cpswells.cps.msu.edu, molen@ece.msstate.edu, kannan@moncol.monmouth.edu, brian_mccarthy@nt.com, kalyani@utdallas.edu, peterson@erc.arizona.edu, czallen@jupiter.eecs.utoledo.edu, besaleh@enga.bu.edu, zaghloul@seas.gwu.edu, krishna@sol.uconn.edu, Stephen.Goodnick@asu.edu, urban@enws88.eas.asu.edu, fickas@cs.uoregon.edu, zzabar@poly.edu, grosky@cs.wayne.edu, john@mtu.edu, erw@armstrong.edu, daniels@seattleu.edu, rwigand@mailbox.syr.edu, dboltman@oru.edu Cc: algirdas.pakstas@hia.no Reply-to: a.pakstas@ieee.org Subject: Workshop On Quality and Productivity for Communications Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Mar 1997 23:16:11 +0100 From: Algirdas Pakstas Message-ID: <"torsk.hia..039:28.02.97.22.24.19"@hia.no> Sorry if you receive mutual copies of this Call for Participation... ------- Forwarded Message The Communications Software committee is co-sponsoring the following workshop. So if you are not interested in attending, then please forward this notice to others you think would be interested. More information can be found on the WWW at http://gump.bellcore.com:8000/ieee/commsoft/workshop.html Thanks, Stan Moyer
International Workshop On Quality and Productivity for Communications in the
next Millennium
May 13-15, 1997 Ojai Valley Inn Ojai, California, USA
Co-sponsored by the IEEE Communications Society Communications Software and Quality Assurance and Management Technical Committees and the IEICE Communications Society Communications Quality Committee
DESCRIPTION The current telecommunications environment is one of change and corporate downsizing. Telecommunications deregulation is creating more telecom firms. Businesses are having to perform the same (or more) functions with fewer people. The time to market for new services and products is decreasing (e.g. the Internet world). At the same time, even more stringent quality standards must be maintained in this era of competition. The goal of this workshop is to bring together end users, service providers and developers from the communications industries to share the latest products, services, processes and methodologies for improving productivity while enhancing quality. Throughout each session, one or more of the following issues should be addressed: How can service providers do more with less? How to rapidly bring new services to market? How to maintain (or improve) quality in rapid development environments. How to maintain quality while outsourcing work. ------- End of Forwarded Message From rem-conf-request@es.net Fri Mar 28 21:48:28 1997 Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service id <06637-0@osi-east2.es.net>; Fri, 28 Mar 1997 21:43:50 -0800 Received: from nanotsu.kobe-u.ac.jp by osi-west.es.net with ESnet SMTP (PP); Fri, 28 Mar 1997 21:43:37 -0800 Received: (from oka@localhost) by nanotsu.kobe-u.ac.jp (8.6.12+2.5Wb3/3.3W9) id OAA23509; Sat, 29 Mar 1997 14:47:31 +0900 Message-Id: <199703290547.OAA23509@nanotsu.kobe-u.ac.jp> To: rem-conf@es.net cc: Mark Handley , rodgers@nlm.nih.gov (R. P. C. Rodgers), dem@hep.net, likavec@igd.fhg.de, shimojo@center.osaka-u.ac.jp Reply-To: oka@nanotsu.kobe-u.ac.jp Subject: Broadcasting of Infocom'97 In-reply-to: Your message of Mon, 24 Mar 1997 17:45:37 EST. <4883.859243537@buttle.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain;charset="ISO-2022-JP" Date: Sat, 29 Mar 1997 14:47:30 +0900 From: Koji OKAMURA We, Cyber Kansai Project, has decided to change the broadcasting schedule of Infocom'97. At the week of 7-11 April, we will broadcast Infocom on only daytime of Japan and will re-broadcast on US daytime at the next or later week. These are our broadcasting plan. Channel 1 Channel 2 === 4/7 === 8:30-17:00(GMT+9) Gigabit Workshop === 4/9 === 8:00-10:00(GMT+9) Keynotes 10:30-12:00(GMT+9) ATM Switching I Wireless Networks I 13:30-15:00(GMT+9) ATM Traffic Control Optical Networks I 15:30-17:00(GMT+9) ATM ABR Services I Panel I: Broadband Service to the Home === 4/10 === 8:30-10:00(GMT+9) ATM ABR Services II Optical Networks II 10:30-12:00(GMT+9) ATM Switching II Wireless Networks II 12:00-13:30(GMT+9) Panel II: Routing vs Switching 13:30-15:00(GMT+9) ATM Traffic Cntrl II Optical Network III 15:30-17:00(GMT+9) ATM ABR Services III Wireless Networks III === 4/11 === 8:30-10:00(GMT+9) ATM Switching III Wireless Networks IV 10:30-12:00(GMT+9) ATM Traffic Cntrl III Panel III: Micro cellular Communication Systems: PHS, DECT and PACS 13:30-15:00(GMT+9) LANs and MANs Optical Networks IV 15:30-17:00(GMT+9) ATM ABR Services IV Wireless Networks V Best Regards. -- Koji From rem-conf-request@es.net Sun Mar 30 06:12:23 1997 Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service id <25600-0@osi-east2.es.net>; Sun, 30 Mar 1997 06:08:59 -0800 Received: from sumo.vocaltec.co.il by osi-west.es.net with ESnet SMTP (PP); Sun, 30 Mar 1997 06:08:52 -0800 Received: from maskit1.vocaltec.co.il (patish.vocaltec.co.il [199.203.72.3]) by sumo.vocaltec.co.il (8.6.12/8.6.12) with SMTP id RAA09677 for ; Sun, 30 Mar 1997 17:06:28 +0200 From: Scott_Petrack@vocaltec.com Received: by maskit1.vocaltec.co.il(Lotus SMTP MTA v1.05 (274.9 11-27-1996)) id 4225646A.004D9C11 ; Sun, 30 Mar 1997 16:07:42 +0200 X-Lotus-FromDomain: VOCALTEC To: rem-conf@es.net Message-ID: <4225646A.004D394C.00@maskit1.vocaltec.co.il> Date: Sun, 30 Mar 1997 16:07:36 +0200 Subject: Anyone not using a hotel reservation or have a spare room on April 7? Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Scott Petrack 03/30/97 04:07 PM I've really screwed up now and didn't properly book a room for the IETF. I have been able to find a room for all days EXCEPT April 7. If anyone has reserved a room that s/he no longer needs, or knows of a spare room for that day, I would be most grateful to hear about it. I of course would prefer a reservation for the full week, rather than switching hotels in the middle for one day, but beggars can't be choosers. Sincerely, Scott Petrack From rem-conf-request@es.net Mon Mar 31 06:50:11 1997 Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service id <07748-0@osi-east2.es.net>; Mon, 31 Mar 1997 06:46:50 -0800 Received: from ietf.org by osi-west.es.net with ESnet SMTP (PP); Mon, 31 Mar 1997 06:46:01 -0800 Received: from ietf.ietf.org by ietf.org id aa04843; 31 Mar 97 9:35 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-crtp-02.txt Date: Mon, 31 Mar 1997 09:35:26 -0500 Sender: cclark@ietf.org Message-ID: <9703310935.aa04843@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Compressing IP/UDP/RTP Headers for Low-Speed Serial Links Author(s) : S. Casner, V. Jacobson Filename : draft-ietf-avt-crtp-02.txt Pages : 20 Date : 03/27/1997 This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. In many cases, all three headers can be compressed to 2-4 bytes. Comments are solicited and should be addressed to the working group mailing list rem-conf@es.net and/or the author(s). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-crtp-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-crtp-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-crtp-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970328112342.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-crtp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-crtp-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970328112342.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Mon Mar 31 12:07:35 1997 Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service id <09847-0@osi-east2.es.net>; Mon, 31 Mar 1997 11:53:34 -0800 Received: from rupertsberg.cs.colorado.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 31 Mar 1997 11:52:28 -0800 Received: (from evi@localhost) by rupertsberg.cs.colorado.edu (8.8.5/8.7.3) id MAA01465; Mon, 31 Mar 1997 12:52:22 -0700 (MST) Date: Mon, 31 Mar 1997 12:52:22 -0700 (MST) From: Evi Nemeth Message-Id: <199703311952.MAA01465@rupertsberg.cs.colorado.edu> To: rem-conf@es.net Subject: IETF Broadcast, April 7-10 Cc: evi@rupertsberg.cs.colorado.edu The IETF meeting held April 7-11 in Memphis, Tennessee, USA will broadcast 2 channels of audio/video/wb of the sessions Monday-Thurs. There will be no broadcasts on Friday. The traditional delayed broadcasts will be done at a later time, during a less busy week for the MBone. We suggest that the other 3 major events during this same week also delay any rebroadcasts so that we can accomodate the bandwidth needs for each of the live events. Maybe we can get the various "radio" stations to shutdown during that week too. We will request that all presenters provide us with postscript that will fit in the whiteboard (<32kbytes/slide) and will stop transmitting video when it is just the speaker roaming around and talking. Others with whiteboard materials might do the same. We usually show the speaker for a minute or two and then stop transmitting, which keeps his/her picture in vic, but does not use further bandwidth. Thanks to everyone for cooperating to make this busy week work. -evi Evi Nemeth IETF Multicast Staff