From rem-conf-request@es.net Thu Dec 01 02:21:30 1994 Received: from ell.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <12494-0@osi-west.es.net>; Wed, 30 Nov 1994 23:21:00 +0000 Received: by ell.ee.lbl.gov (8.6.9/1.43r) id XAA28042; Wed, 30 Nov 1994 23:20:58 -0800 From: mccanne@ee.lbl.gov (Steven McCanne) Message-Id: <199412010720.XAA28042@ell.ee.lbl.gov> To: rem-conf@es.net Subject: Mark Garrett on MBONE (Dec 1, 1:00-2:00pm PST) Date: Wed, 30 Nov 94 23:20:58 PST This is a reminder that Mark Garrett will be giving a talk on ``Designing Real Quality of Service into ATM and the Internet'' Thursday at 1pm PST. The session is announced in sd, as ``Garrett QOS Talk (*)''. We will be distributing video over RTPv2 in H.261 format, which is viewable with the UCB/LBL video conferencing tool, vic (see ftp://ftp.ee.lbl.gov/conferecing/vic). Slides will be disseminated via wb. Since they are on the large size, we've LZ-compressed them. Unfortunately, some display postscript severs do not support LZ-compressed postscript (notably DEC's dps server). In this case, you'll need to run wb with ghostscript instead, by setting wb*UseDPS to false (of course, ghostscript must be installed too). Steve From rem-conf-request@es.net Thu Dec 01 05:31:24 1994 Received: from jaring.my by osi-west.es.net via ESnet SMTP service id <14112-0@osi-west.es.net>; Thu, 1 Dec 1994 02:27:33 +0000 Received: from srb.UUCP by jaring.my with UUCP id AA05006 (5.67a/IDA-1.5 for rem-conf@es.net); Thu, 1 Dec 1994 18:27:25 +0800 Message-Id: <199412011027.AA05006@jaring.my> Received: from srb by srb.pl.my (UUPC/extended 1.12b) with UUCP; Wed, 30 Nov 1994 18:29:38 GMT From: Saravana Ram Balakrishnan To: rem-conf@es.net Date: Wed, 30 Nov 1994 18:29:37 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: Join? Reply-To: Saravana Ram Balakrishnan X-Pmrqc: 1 Priority: normal X-Mailer: PMail v3.0 (R1a) > From: Self > To: rem-conf@es.net > Subject: Join? > Send reply to: "Saravana Ram Balakrishnan" > Date sent: Wed, 30 Nov 1994 08:56:54 > Is think this is how you join? To all readers, I am very sorry for this mistake and will now subscribe to the right address(I hope). I very much regret for the inconvinience. I have, though, recieved some "notices" and have been "gently flamed" by some. And here are the top two: ---------------------------------------------------------------------- Realize you may know better, but a message got to me that has to do with administrivia on a list, so a gentle reminder is in order. In general, to do ANY administrative thing on ANY internet mailing list one sends mail to the list name with -REQUEST appended. For example, the administrivia address for is . Yes,-REQUEST can be lowercase also, as in . Of course, the advice above is predicated on your being interested in the master list. However, if you are trying to unsubscribe and are getting your copy from a secondary exploder, you need to send a message to the exploder administrivia address. You may want/need to to look at the headers for of a typical mail message from the list to determine whether you are on the master list or an exploder. Or, asking your postmaster to look at the headers for you would work too. In addition, for a lot of lists you should not plan on having the list administrator reading the list. Be PATIENT, the humans that do mailing list maintenance often do that as an ancillary task and sometimes have to do their "real" jobs and the list maintenance takes a lesser priority. Later, Ken ---------------------------------------------------------------------- Saravana Ram Balakrishnan, On Wed, 30 Nov 1994 08:56:54 you sent an (un)subscribe message to *the entire list*. You made a common error. You should send e-mail regarding (un)subscription requests to the e-mail address "-request" at the same hostname. Since this is not uniquely defined, you could try to send it to "listserv" or "majordomo" at the same hostname if the -request does not work. In case you already tried to reach the "-request" mailbox, without any luck so far, and you are now addressing the entire list to notify the list manager, please be patient next time, since list managers can be busy people. What you just did may trigger more people, so please be aware that you might receive more messages like this one. Please try to remember not to address the entire list for these purposes in the future. Thank you for your cooperation. __ Erik-Jan's (un)subscribe detection and reply program. ---------------------------------------------------------------------- -- Saravana Ram Balakrishnan Tel: +60-3-255-9841 ram@srb.pl.my From rem-conf-request@es.net Thu Dec 01 11:15:27 1994 Received: from sun10or.or.nps.navy.mil by osi-west.es.net via ESnet SMTP service id <16348-0@osi-west.es.net>; Thu, 1 Dec 1994 08:14:51 +0000 Received: from castor.nps.navy.mil (castor.or.nps.navy.mil) by sun10or.or.nps.navy.mil (4.1/SMI-4.1) id AA17153; Thu, 1 Dec 94 08:15:49 PST Received: by castor.nps.navy.mil (5.0/SMI-SVR4) id AA02284; Thu, 1 Dec 1994 08:13:53 +0800 Date: Thu, 1 Dec 1994 08:13:53 +0800 From: gerchman@sun10or.or.nps.navy.mil (Kenn Gerchman) Message-Id: <9412011613.AA02284@castor.nps.navy.mil> To: rem-conf@es.net X-Sun-Charset: US-ASCII Content-Length: 12 unsubscribe From rem-conf-request@es.net Fri Dec 02 05:14:15 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <24759-0@osi-west.es.net>; Fri, 2 Dec 1994 02:13:45 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-19) id ; Fri, 2 Dec 1994 02:13:41 -0800 Posted-Date: Fri 2 Dec 94 02:12:32 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Fri, 2 Dec 94 02:12:32 PST Date: Fri 2 Dec 94 02:12:32 PST From: Stephen Casner Subject: RTP SDES code assignments To: rem-conf@es.net Message-Id: <786363152.0.CASNER@XFR.ISI.EDU> Mail-System-Version: To the Audio/Video Transport WG and others interested in RTP: One of the items listed as an open issue in draft-ietf-avt-rtp-06.txt is the recommendation to change the numberic codes assigned for the RTCP packet types (SR, RR, etc.) to 201 decimal and up. The purpose is to aid header validity checking. These numbers would have more bits to be on in that field to be different from random packets (since 0 is the most common value) and from the assigned payload types in an RTP data packet (in case RTP or RTCP packets are directed to the wrong port). Future code assignments are not an issue because any "stack" of RTCP packets is supposed to begin with an SR, RR, or BYE. My question is to any of you who have already implemented RTP: would it be a significant hardship to change these numbers? Consider that there are other changes, such as making the length of SDES items be zero-based, that would make existing implementations of the -05 draft incompatible anyway. Also, the whole idea of a draft is that it may change! We'll discuss this at the IETF meeting, but email answers to the question above as well as other comments on whether this is a good idea or bad are solicited, especially from those who can't attend. -- Steve ------- From rem-conf-request@es.net Fri Dec 02 05:24:59 1994 Received: from ceres.fokus.gmd.de by osi-west.es.net via ESnet SMTP service id <24838-0@osi-west.es.net>; Fri, 2 Dec 1994 02:24:27 +0000 Received: from fokus.gmd.de by ceres.fokus.gmd.de id <26936-0@ceres.fokus.gmd.de>; Fri, 2 Dec 1994 11:22:53 +0100 Subject: rtpdump 1.0 To: rem-conf@es.net MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Fri, 2 Dec 1994 11:22:53 +0100 From: Henning Schulzrinne Sender: schulzrinne@fokus.gmd.de I have created a small applet that dumps RTP and RTCP packets given a port and an optional multicast address. Being version 1.0, it can likely be much improved; thus, comments are appreciated. ftp://gaia.cs.umass.edu/pub/hgschulz/rtp/rtpdump-1.0.tar.gz -- Henning Schulzrinne email: hgs@fokus.gmd.de GMD-Fokus phone: +49 30 25499 182 ; Fri, 2 Dec 1994 03:42:59 +0000 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.9/8.6.6) id MAA20347; Fri, 2 Dec 1994 12:42:44 +0100 Message-Id: <199412021142.MAA20347@cismsun.univ-lyon1.fr> Subject: Re: nv on DEC Alpha To: beaupre@draper.com Date: Fri, 2 Dec 1994 12:42:42 +0100 (MET) From: Lucia Gradinariu Cc: rem-conf@es.net In-Reply-To: <9411302013.AA01848@ginsu> from "beaupre@draper.com" at Nov 30, 94 03:13:28 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1286 Hi, > > Dec's driver for J300 Sound&Motion board is available on > >http://chocolate.pa.dec.com/mbone/j300.tar.Z (jv2driver) and it > >works very nice with nv3.3. > >Thanks to berc@pa.dec.com. > > > >lucia@univ-lyon1.fr > > > How would I use this driver? I obtained the driver but all > it is is a binary. What do I do with it? How do I build it > into nv? If you could point me to a source with this information, > I would be grateful. I put this on the list for all those having nv3.3 binaries compiled with "without MME " option on a DEC Alpha + J300 You can make your choice if you have both MME and jv2driver by changing this option into the Makefile of nv sources distribution (you have to have tcl/tk installed on your machine to compile sources). Also, perhaps you may know the answer to > another question: I currently built nv to use the MME software > from Digital. It built fine but when I run nv, I get a color > video image which is very green (the color is incorrect). The > greyscale feature is beautiful though. Any ideas? As I observed, you have to feed NTSC video signal into the J300 video card in order to get color. I don't think it recognizes PAL or SECAM video format (as SunVideo does :-)) Hope it helps!. Lucia.Gradinariu@univ-lyon1.fr From rem-conf-request@es.net Fri Dec 02 09:01:36 1994 Received: from cs.tut.fi by osi-east.es.net via ESnet SMTP service id <02263-0@osi-east.es.net>; Fri, 2 Dec 1994 06:01:11 +0000 Received: from isosotka.cs.tut.fi (mit@isosotka.cs.tut.fi [130.230.17.14]) by cs.tut.fi (8.6.9/8.6.4) with ESMTP id PAA01407; Fri, 2 Dec 1994 15:58:56 +0200 From: Tsokkinen Mikko Received: (mit@localhost) by isosotka.cs.tut.fi (8.6.8/8.6.4) id PAA15436; Fri, 2 Dec 1994 15:58:52 +0200 Date: Fri, 2 Dec 1994 15:58:52 +0200 Message-Id: <199412021358.PAA15436@isosotka.cs.tut.fi> To: Van Jacobson Cc: rem-conf@es.net Subject: Re: vic v2.5 available for anonymous ftp In-Reply-To: <9411301356.AA05775@rx7.ee.lbl.gov> References: <9411301356.AA05775@rx7.ee.lbl.gov> Van Jacobson writes: >A new version of the UCB/LBL video tool vic is available for anonymous >ftp from ftp.ee.lbl.gov in directory conferencing/vic. v2.5 fixes >a number of problems that showed up in the initial release. Attached >is a list of the changes. I just tried vic on SS20/Z50/SX/SunVideo/Solaris2.3. I have few comments: How come "vic" is so much slower than "showme"? Cellb encoding of PAL CIF with "showme" is 25 fps and with "vic.rtvc" it is only 4 fps. I could not use "vic.xil" because it gives me following error message when I try to encode: ld.so.1: ./vic.xil: fatal: relocation error: symbol not found: xil_device_create: referenced in ./vic.xil Killed Otherwise the program looked great. Is there a Solaris2.3 parallax version coming in the near future? Mikko Tsokkinen Digital Media Institute, Tampere University of Technology Research Assistant - Project FASTER Distributed Multimedia Applications over ATM-Network From rem-conf-request@es.net Fri Dec 02 12:35:07 1994 Received: from inet-gw-2.pa.dec.com by osi-west.es.net via ESnet SMTP service id <28353-0@osi-west.es.net>; Fri, 2 Dec 1994 09:34:41 +0000 Received: from oreo.pa.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA26367; Fri, 2 Dec 94 09:25:58 -0800 Received: by oreo.pa.dec.com; id AA11217; Fri, 2 Dec 94 09:25:47 -0800 Message-Id: <9412021725.AA11217@oreo.pa.dec.com> To: Lucia Gradinariu Cc: beaupre@draper.com, rem-conf@es.net Subject: Re: nv on DEC Alpha In-Reply-To: Message of Fri, 2 Dec 1994 12:42:42 +0100 (MET) from Lucia Gradinariu <199412021142.MAA20347@cismsun.univ-lyon1.fr> Date: Fri, 02 Dec 94 09:25:46 -0800 From: berc@src.dec.com X-Mts: smtp To use jv2driver with PAL cameras, start it with -pal. To use it with svideo input. start it with -sin (or -sout for S-Video out). One of these days I'll fix it so that these options (and which video in) can be set from applications. From rem-conf-request@es.net Fri Dec 02 15:36:40 1994 Received: from ell.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <00227-0@osi-west.es.net>; Fri, 2 Dec 1994 12:36:17 +0000 Received: by ell.ee.lbl.gov (8.6.9/1.43r) id MAA01537; Fri, 2 Dec 1994 12:36:08 -0800 From: mccanne@ee.lbl.gov (Steven McCanne) Message-Id: <199412022036.MAA01537@ell.ee.lbl.gov> To: Tsokkinen Mikko cc: rem-conf@es.net Subject: Re: vic v2.5 available for anonymous ftp In-reply-to: Your message of Fri, 02 Dec 94 15:58:52 +0200. <199412021358.PAA15436@isosotka.cs.tut.fi> Date: Fri, 02 Dec 94 12:36:08 PST > I just tried vic on SS20/Z50/SX/SunVideo/Solaris2.3. Vic and the tk event loop tickle bugs in Solaris-2.3. >From the vic README: o Due to bugs in the Solaris-2.3 poll system call, vic is pretty much useless under 2.3. You should upgrade to 2.4. The performance in showme is better most likely because they worked around the kernel bugs in the application. > I could not use "vic.xil" because it gives me following error message > when I try to encode: > ld.so.1: ./vic.xil: fatal: relocation error: symbol not found: xil_device_cre ate: referenced in ./vic.xil This is also a solaris-2.3 incompatibility. The xil api has changed >from 2.3 to 2.4. > Is there a Solaris2.3 parallax version coming in the near future? We don't have a parallax board and haven't heard that anyone has started the port. (Please use vic@ee.lbl.gov for vic related correspondence.) Steve From rem-conf-request@es.net Fri Dec 02 16:20:40 1994 Received: from comm.cpd.tandem.com by osi-west.es.net via ESnet SMTP service id <00572-0@osi-west.es.net>; Fri, 2 Dec 1994 13:20:12 +0000 Received: by comm.Tandem.COM (4.12/4.5) id AA11065; 2 Dec 94 13:20:22 -0800 Date: 2 Dec 94 10:45:00 -0800 From: KIM_ANDY@tandem.com Message-Id: <199412021320.AA11065@comm.Tandem.COM> To: rem-conf@es.net Subject: unsubscribe unsubscribe From rem-conf-request@es.net Fri Dec 02 17:23:24 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <01100-0@osi-west.es.net>; Fri, 2 Dec 1994 14:23:00 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-19) id ; Fri, 2 Dec 1994 14:22:57 -0800 Posted-Date: Fri 2 Dec 94 14:21:47 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Fri, 2 Dec 94 14:21:48 PST Date: Fri 2 Dec 94 14:21:47 PST From: Stephen Casner Subject: No "Jazz stars" sessions, please To: pjj@norppa.dat.tele.fi Cc: MBONE@ISI.EDU, rem-conf@es.net Message-Id: <786406907.0.CASNER@XFR.ISI.EDU> Mail-System-Version: This note is to pjj@norppa.dat.tele.fi in particular, but a general reminder to the community also seems warranted. Please do not create sessions like the "Jazz stars" session you have now. It would be nice if everyone could send out the kind of music that they like, but the bandwidth available on the MBone is very limited. If there is too much traffic, all the users suffer. Long ago I created a fake session "** Please don't start a radio session" that shows up at the top of the sd list. It's intent is to defer the creation of sessions like yours. As it says, there is one session, Radio Free Vat, on which people can sign up for slots to play music. Even then, that channel is supposed to be quiet when there are other "more important" events such as conferences being broadcast. Right now the FMC conference is going on, for example, and all next week the MBone will be very busy with transmissions from the IETF meeting. After two years, I think the MBone has shown itself to be a good idea worth continuing. It is now time to work on the next phase, getting the capacity increased so that we can allow multiple events to be transmitted at once. And beyond that, getting "Integrated Services" implemented in the Internet to give better performance for real-time traffic. But until those steps are successful, cooperation of all users is the key. Besides, your music is stuck. It is repeating about 1 second worth of sound over and over. This is a complete waste of bandwidth! Please stop. -- Steve ------- From rem-conf-request@es.net Sat Dec 03 10:46:53 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <08174-0@osi-west.es.net>; Sat, 3 Dec 1994 07:46:23 +0000 Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 3 Dec 1994 15:45:43 +0000 To: Stephen Casner cc: pjj@norppa.dat.tele.fi, MBONE@ISI.EDU, rem-conf@es.net Subject: Re: No "Jazz stars" sessions, please In-reply-to: Your message of "Fri, 02 Dec 94 14:21:47 PST." <786406907.0.CASNER@XFR.ISI.EDU> Date: Sat, 03 Dec 94 15:45:36 +0000 From: Gordon Joly Steve, All agreed. And it seems that if you want music you should join the parallel world of Cu Seeme, and leave the MBONE alone for the research to continue. Or run pruning. Gordo >>>>> On Fri, 02 Dec 94 16:25:47 EST, jher said: jher> -- using template mhl.format -- jher> From: jher jher> Subject: Another online concert for your enjoyment! jher> Return-Path: jher> Reply-To: jher@eden.com jher> Sender: owner-CU-SEEME-L@cornell.edu jher> MIME-Version: 1.0 jher> Content-Type: TEXT/PLAIN; charset=US-ASCII jher> X-PH: V4.1@cornell.edu (Cornell Modified) jher> X-Listprocessor-Version: 7.1 -- ListProcessor by CREN jher> We will be showing "Machine Screw" live from The Electric Lounge jher> here in Austin, Tx on Monday, Dec. 5th starting at 11:30 pm CST. jher> The reflector is jher> 199.171.21.1 jher> Thanks for tuning in. jher> If you cut off your ears in a forest, do all the trees fall down? jher> jher@matrix.eden.com jher@fnord.org jher> SysAdmin eden.com Moron fnord.org jher> http://www.eden.com/~jher Gordon Joly Email: G.Joly@cs.ucl.ac.uk +441713807934 FAX +441713871397 Computer Science, University College London, Gower St., LONDON WC1E 6BT http://www.cs.ucl.ac.uk/people/gordo/ http://artaids.dcs.qmw.ac.uk:8001/ From rem-conf-request@es.net Sat Dec 03 14:41:01 1994 Received: from inet-gw-2.pa.dec.com by osi-west.es.net via ESnet SMTP service id <09265-0@osi-west.es.net>; Sat, 3 Dec 1994 11:40:37 +0000 Received: from oreo.pa.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA23589; Sat, 3 Dec 94 11:38:19 -0800 Received: by oreo.pa.dec.com; id AA16256; Sat, 3 Dec 94 11:38:13 -0800 Message-Id: <9412031938.AA16256@oreo.pa.dec.com> To: Gordon Joly Cc: Stephen Casner , pjj@norppa.dat.tele.fi, MBONE@ISI.EDU, rem-conf@es.net Subject: Re: No "Jazz stars" sessions, please In-Reply-To: Message of Sat, 03 Dec 94 15:45:36 +0000 from Gordon Joly <9412031640.AA14117@inet-gw-2.pa.dec.com> Date: Sat, 03 Dec 94 11:38:12 -0800 From: berc@src.dec.com X-Mts: smtp I wouldn't have minded the Jazz Stars session if the CD had decided to skip, thus repeating the same five second interval all day. Over 200 sites were hooked to the Rolling Stone's live broadcast, which is far more than I've seen for any other mcast at one time. Other events, such as the Space Shuttle or IETF have more listeners, but that's spread over several days. Most of the music sessions have taken place off hours. They consume little bandwidth, which is not the kind of resource you can reserve for a rainy day. Either it gets used, or it's gone. If someone wants to send out some live music starting at 11:30pm CST (5:30am in Britain), more power to them. If the MBone can't scale for this sort of occasional use than we've learned something. lance From rem-conf-request@es.net Sat Dec 03 18:11:51 1994 Received: from viipuri.nersc.gov by osi-east.es.net via ESnet SMTP service id <26186-0@osi-east.es.net>; Sat, 3 Dec 1994 15:11:24 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA23744; Sat, 3 Dec 94 15:11:20 PST Date: Sat, 3 Dec 94 15:11:20 PST From: ari@es.net (Ari Ollikainen) Message-Id: <9412032311.AA23744@viipuri.nersc.gov> To: CASNER@isi.edu, G.Joly@cs.ucl.ac.uk Subject: Re: No "Jazz stars" sessions, please Cc: MBONE@isi.edu, pjj@norppa.dat.tele.fi, rem-conf@es.net > Date: Sat, 03 Dec 94 15:45:36 +0000 > From: Gordon Joly > Status: RO > > Steve, > > All agreed. And it seems that if you want music you should join the > parallel world of Cu Seeme, and leave the MBONE alone for the research > to continue. Or run pruning. > Does Cu-SeeMe occupy bandwidth on some *other* Internet? Any Mac owner with Internet access can equip his Mac with the new *serial*port* connected QuickCam digital camera from ConnecTix for less than $100 and become a source of Cu-SeeMe grayscale video. If you're worried about scaling and appropriate use of MBone bandwidth, now... Ari@ES.net _/_/ _/_/_/_/ _/ Ari Ollikainen {VOX: 510 423-5962} _/ _/ _/ _/ _/ Energy Sciences Network {FAX: 510 423-8744} _/_/_/_/ _/_/_/_/ _/ National Energy Research Supercomputer Center _/ _/ _/ _/ _/ Lawrence Livermore National Laboratory _/ _/ _/ _/ _/ MailStop L-561, PO BOX 5509, Livermore, CA. 94551 ~~RECOM Technologies Inc.~~ From rem-conf-request@es.net Sat Dec 03 19:06:17 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <10717-0@osi-west.es.net>; Sat, 3 Dec 1994 16:05:37 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-19) id ; Sat, 3 Dec 1994 14:10:02 -0800 Posted-Date: Sat 3 Dec 94 14:04:02 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Sat, 3 Dec 94 14:04:03 PST Date: Sat 3 Dec 94 14:04:02 PST From: Stephen Casner Subject: Re: No "Jazz stars" sessions, please To: berc@src.dec.com Cc: MBONE@ISI.EDU, rem-conf@es.net Message-Id: <786492242.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9412031938.AA16256@oreo.pa.dec.com> Mail-System-Version: I want to emphasize that I like music, and that I think there are times when it is a good thing for music to be sent over the MBone (though I'd much rather have hi-fi than lo-fi). My concern is this: it is easy for anyone on the MBone to hook up a CD player and start sending music, or patch in the local college radio station to send music continuously. If one person does it, it will look like a good idea to the next person, too, and pretty soon the bandwidth is gone, all the time. The Radio Free Vat channel is intended to allow people to play music in this manner, but by restricting to a single channel with sign-up slots we avoid the explosion. Furthermore, the act of signing up for a slot provides an opportunity to supply some guidelines on bandwidth sharing, for example, that RFV is supposed to be silent when scheduled events are underway, as was the case yesterday while "Jazz stars" was underway. My opinion is that we can make the best use of the MBone bandwidth by transmitting special events that aren't available through another medium. Most of the events are seminars and conferences, but the cultural events, including live concerts, fall into this category, too. Note that NASA Select is available via satellite, and covers each mission covers a long time span, so the folks that send it are cooperative in giving it a lower priority when needed -- reducing the data rate or shutting down the signal. I agree completely that unused bandwidth can't be reserved, and I think it is good to have RFV exercising the MBone then. This was particularly useful in the early days. And it is important to have pruning in place so that the traffic does not flow over links where it would be considered "wasting" rather than "exercising". But be careful with the notion of "off hours" -- this is a 24-hour network. Lance> If the MBone can't scale for this sort of occasional use than Lance> we've learned something. The key word is "occasional", and my chief concern is potentially continuous sources. Clearly the MBone is not a general-purpose service, it is still experimental. As I said, it is time to start pushing on scaling up the MBone bandwidth, but it won't happen immediately. Gordo> And it seems that if you want music you should join the Gordo> parallel world of Cu Seeme ... The parallel world doesn't load down MBone nodes, but it loads links just the same (or worse when multiple copies flow), so this is at least as big a concern. I didn't want to start a long discussion, especially with cross posting to both mbone and rem-conf, so I'll stop with this msg. (I considered blind cc'ing to the lists on my first message, but that didn't seem right, either.) -- Steve ------- From rem-conf-request@es.net Sun Dec 04 04:55:58 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <14335-0@osi-west.es.net>; Sun, 4 Dec 1994 01:55:25 +0000 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 4 Dec 1994 09:50:33 +0000 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: Stephen Casner cc: berc@src.dec.com, rem-conf@es.net Subject: Re: No "Jazz stars" sessions, please In-reply-to: Your message of "Sat, 03 Dec 94 14:04:02 PST." <786492242.0.CASNER@XFR.ISI.EDU> Date: Sun, 04 Dec 94 09:49:13 +0000 Message-ID: <421.786534553@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk [mbone deleted from cc list] >I want to emphasize that I like music, and that I think there are >times when it is a good thing for music to be sent over the MBone >(though I'd much rather have hi-fi than lo-fi). It's an interesting cultural phenomena that people will listen to PCM audio on the Mbone, when for very little money they can but a cheap radio (if they don't already have one) and get much better quality and more choice! In the long run I'd love to see the internet/mbone or whatever succeeds them become the broadcast medium of choice. With deployment of the right multicast implementations, if no-one is listening, no traffic goes anywhere, so this seems much less wasteful of limited spectrum than current broadcast media. The potential for non-geographic (ie not restricted by national boundaries) distribution of news has far reaching implications for opressive government and freedom of speech. However, clearly it's not ready for the "big time" right now. As a side issue, at least in the UK, unauthorised broadcasting of copyright material (and that includes music) is illegal. Radio stations here have to pay the music company to play their recordings. It's very unclear whether running an mrouted counts as running a re-broadcaster, and therefore is illegal if someone multicasts copyright music from outside the UK. I've no idea what the situation is elsewhere. Mark From rem-conf-request@es.net Sun Dec 04 11:48:10 1994 Received: from rx7.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <16280-0@osi-west.es.net>; Sun, 4 Dec 1994 08:47:43 +0000 Received: by rx7.ee.lbl.gov for rem-conf@es.net (5.65/1.44r) id AA14320; Sun, 4 Dec 94 08:50:52 -0800 Message-Id: <9412041650.AA14320@rx7.ee.lbl.gov> To: ietf@ietf.cnri.reston.va.us, rem-conf@es.net Subject: new wb (1.59) available for anonymous ftp Date: Sun, 04 Dec 94 08:50:51 PST From: Van Jacobson There's a new version of the LBL whiteboard tool available at ftp://ftp.ee.lbl.gov/conferencing/wb/*-wb-1.59.tar.Z (where '*' can be sun, dec, decalpha, i386, sgi or hp). If you are planning to watch the IETF31 multicast, we *strongly* request that you pick up this version of wb -- it contains some fixes to the retransmit algorithm that should make it behave much better than previous versions. There are also a number of other fixes (see attached change log). Thanks. - Van Jacobson & Steve McCanne ------------------------------- v1.59, Sun Dec 4 01:03:30 PST 1994 ****** PLEASE NOTE ****** Version 1.59 of wb requires changes to your .sd.tcl file. The file NOTES contains a new wb script that should replace the one in your .sd.tcl. ************************* - make `receiveOnly' default to true to minimize damage from scribblers who don't update their sd.tcl. (suggested by Steve Casner) - were treating postscript strings with embedded '%' as comments and discarding rest of line when printing ps files. (this particularly affected mac ps files & converted them to invalid postscript). (bug reported by Paul Suhler suhler@xanthus.usc.edu & Greg Earle earle@isolar.Tujunga.CA.US). - loosen up the definition of a 'point' for click-and-type to make it easier for caffeine junkies to type in strings. (suggested by Steve Deering & Deborah Estrin) - make printing work on an Alpha running osf/1 - rewrote interviews pager to get rid of some of the weird page flipping behavior (double stepping, bouncing pages just after flip in large conf, etc.). - just complain, don't abort, if user tries to import a ps file with bad structure. - don't coredump if we change page orientation after a postscript error has caused ps interpreter to exit. - do a lot more sanity checking on incoming packets to try to avoid coredumps from bad drawops. - font scaling stuff from 1.58 was pretty broken: need to flush font cache when page is resized and need to scale x font widths by current page scale factor or text gets all scrunched up. - implement Sally Floyd's suggestion on a deadtime after a repair response to flush duplicate repair requests. From rem-conf-request@es.net Sun Dec 04 14:16:56 1994 Received: from lanshark.hstf.interop.net by osi-west.es.net via ESnet SMTP service id <17016-0@osi-west.es.net>; Sun, 4 Dec 1994 11:16:33 +0000 Received: (from ericd@localhost) by lanshark.hstf.interop.net (8.6.9/8.6.9) id LAA19231; Sun, 4 Dec 1994 11:22:52 -0800 Date: Sun, 4 Dec 1994 11:22:51 -0800 (PST) From: Eric Davis To: rem-conf@es.net Subject: MBONE Music Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII There has been much discussion at The Internet Underground Music Archive (IUMA) regarding a MBONE radio station. We were going to post info later this month, however with the recent talks about radio stations I figure now is a good time. First Jazz Stars, is your silence detection off? Anyway back to IUMA. IUMA has hundreds of unsigned bands with music, bios, etc available for WWW/FTP access on the net. (www.iuma.com) The idea behind IUMA is that musicians should have the chance to get their music published (which is what we are currently doing) without being blocked or extorted by the "Record Company Mega Giants" playing god. Radio is the next logical step for IUMA. Every musician should have the ability to have their music broadcast without the "Record Company Mega Giants" playing god with promotional kickbacks to your local radio station. We are thinking of placing a radio station on the air. We want to the model to be slightly different than the standard Radio Free VAT, more interactive, call it a social testbed. 1. We would place non-commercial music on the net. This would be music we have the rights to replay without copyright problems. This would be placed on the net at the lowest "ok" sounding BW (32K?). Anyone would be allowed to give IUMA music for inclusion on the play-list, or schedule a time slot. 2. Have a HTTP pointer to IUMA where listeners can be pointed to the URL of the band that is currently playing, past songs, and future songs. They can see photos, read the bands bio, download more songs, contact the artists, etc.. **NEAT FEATURE** 3. Have a HTTP URL at IUMA that will allow users to select music to be played. It would have the standard JukeBox selection process, more requests would move the song closer to the top, within reason. We really want to provide structured content to the net! Details regarding the project, feedback, etc. would be freely accesable. Any thoughts? With my Interop hat on, we would like to help where possible (talent, space, equipment) with increasing the national MBONE available bandwidth. Eric Davis Network Roadie ericd@iuma.com Eric Davis SR. Network Engineer ericd@interop.net From rem-conf-request@es.net Sun Dec 04 14:58:40 1994 Received: from punch.ic.ac.uk by osi-west.es.net via ESnet SMTP service id <17230-0@osi-west.es.net>; Sun, 4 Dec 1994 11:58:06 +0000 Received: from phdmsa-gw1.tp.ph.ic.ac.uk by punch.ic.ac.uk with SMTP (PP) id <29175-0@punch.ic.ac.uk>; Sun, 4 Dec 1994 19:50:34 +0000 Received: from zeno.tp.ph.ic.ac.uk by plato.tp.ph.ic.ac.uk (4.1/4.0) id AA00707; Sun, 4 Dec 94 19:50:31 GMT From: tpmsc46@ic.ac.uk Message-Id: <1864.9412041950@zeno.tp.ph.ic.ac.uk> Subject: Re: No "Jazz stars" sessions, please To: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Sun, 4 Dec 94 19:50:30 GMT Cc: CASNER@ISI.EDU, berc@src.dec.com, rem-conf@es.net In-Reply-To: <421.786534553@cs.ucl.ac.uk>; from "Mark Handley" at Dec 4, 94 9:49 am X-Mailer: ELM [version 2.3 PL11] Mark Handley wrote: > > As a side issue, at least in the UK, unauthorised broadcasting of > copyright material (and that includes music) is illegal. Radio > stations here have to pay the music company to play their recordings. > It's very unclear whether running an mrouted counts as running a > re-broadcaster, and therefore is illegal if someone multicasts > copyright music from outside the UK. I've no idea what the situation > is elsewhere. I'd say it would have to be a re-broadcast. The router has no choice over what is transmitted (without shutting the software down) and the retransmission is immediate. The only other possibility would be that it is a cable broadcast, and that seems impossible from the language used in the remainder of the 1988 Act. As editor of an Internet newspaper I am interested in this subject; material broadcast for the first time over the Internet or any other electronic medium (classified as a cable programme) is held to have the broadcaster as author, and therefore the first copyright ownership resides with the broacasting organisation. Of course this is overridden by any agreement the broadcaster might have with the real author, but it seems to be a hole, and one that artists should be aware of. Again, I don't know how closely this applies in other countries, but it is the case in the UK. Leigh From rem-conf-request@es.net Mon Dec 05 03:51:57 1994 Received: from ell.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <21918-0@osi-west.es.net>; Mon, 5 Dec 1994 00:51:28 +0000 Received: by ell.ee.lbl.gov (8.6.9/1.43r) id AAA10594; Mon, 5 Dec 1994 00:51:25 -0800 From: mccanne@ee.lbl.gov (Steven McCanne) Message-Id: <199412050851.AAA10594@ell.ee.lbl.gov> To: rem-conf@es.net Subject: vic-2.6 BETA released Date: Mon, 05 Dec 94 00:51:25 PST There's a new version of vic available for anonymous ftp >from ftp.ee.lbl.gov in conferencing/vic. Lots of bug fixes and a few new enhancements -- see the change list below. Thanks for all the great feedback. - Steve McCanne & Van Jacobson -------------- v2.6beta Mon Dec 5 00:26:42 PST 1994 - Changed VIC.SD.TCL script to use ivs (instead of vic in ivs compat mode) by default, since ivs' rate control scheme depends on feedback reports that vic does not generate. - Made H.261 decoder more robust to packet loss and reordering. Problem reported by terje.vernly@usit.uio.no. - Upgrade release status from ALPHA to BETA. - Incorporated John Brezak's (brezak@apollo.hp.com) changes to support generic Xvideo devices. He says: o You need a fixed libXv.a (get the source from ftp.x.org and apply patch in grabber-xv.cc) o Haven't implemented cif_grabber(). Maybe next week. o There are 2 config options - XV_PSEUDO8 and XV_USES_XSHM . XV_PSEUDO8 is for allowing an 8bit visual to be used to supply a capture window for a 24bit image. HP does this. XV_USES_XSHM is for an Xv extension that can use the SHM versions of image operations. Parallax currently doesn't support this on HP. - Incorporated Greg Earle's (earle@isolar.Tujunga.CA.US) and Paul Kranenburg's (independent) patches for NetBSD/sparc. - Fixed bug that caused core dump when deleting local thumbnail. Report by George Michaelson . - Fixed "can't unset name_line" bug. Reported by Steve Casner (casner@isi.edu) and others. - Fixed bug that caused video capture to hang when switching input ports with SunVideo. Reported by speer@eng.sun.com (Michael Speer). - Fixed VIC.SD.TCL to generated -I options correctly for voice-switched operation. Bug report and fix from a61@nikhef.nl (Herman van Dompseler). - Arranged for viewing windows to be remapped without user placement at the same location and size when dismissed (suggestion from George Michaelson). - Fix bug that unecessarily caused decoder data structures to be created and destroyed when initializing a new stream (fix from Bernd Lamparter ). - Fix bug that caused error message when invoking release button at wrong time. Reported by a61@nikhef.nl (Herman van Dompseler). - Fix bug that caused error message when invoking lock button at wrong time. Reported by Dan Molinelli and several others. From rem-conf-request@es.net Mon Dec 05 04:13:04 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <22096-0@osi-west.es.net>; Mon, 5 Dec 1994 01:12:33 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 5 Dec 1994 09:12:17 +0000 To: Eric Davis cc: rem-conf@es.net Subject: Re: MBONE Music In-reply-to: Your message of "Sun, 04 Dec 94 11:22:51 PST." Date: Mon, 05 Dec 94 09:12:15 +0000 Message-ID: <1039.786618735@cs.ucl.ac.uk> From: Jon Crowcroft one way of making this less contentios would be if sd permitted priorities - then people copuld start up sessions like the IETF broadcast at high priority, whilst the radio sessions would be lower if then all the tools around (vat,vic,ivs,nv,wb) all promiscuously listend to session messages, and respected the priority of other sessions, we could implement a global backoff by less important sessions when more important ones are live.... ivs, for example, already adapts to loss - it would be trivial to make it adapt to 'Very Important People's' session messages, and back off further.... then we wouldn't even have to wait for RSVP and CSZ or CBQ routers.... jon From rem-conf-request@es.net Mon Dec 05 05:49:06 1994 Received: from swan.cl.cam.ac.uk by osi-west.es.net via ESnet SMTP service id <22960-0@osi-west.es.net>; Mon, 5 Dec 1994 02:48:17 +0000 Received: from mallard.cl.cam.ac.uk (user pb (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Mon, 5 Dec 1994 10:47:47 +0000 To: rem-conf@es.net, mbone@ISI.EDU Cc: Piete.Brooks@cl.cam.ac.uk, Graham.Titmus@cl.cam.ac.uk, Ross.Anderson@cl.cam.ac.uk Reply-To: Piete.Brooks@cl.cam.ac.uk Subject: Mbone transmission 94/12/05 16:15-17:15 UTC (cl.cam.ac.uk Security) Date: Mon, 05 Dec 1994 10:47:42 +0000 From: Piete Brooks Message-ID: <"swan.cl.cam.:093530:941205104759"@cl.cam.ac.uk> We are **LIKLEY** to be transmitting an extra Security Seminar which has been arranged at short notice. I have been told that I can tape the seminar, but have not yet had an ACK that I can MBone it. However, it appears likley. As such, ther may be a last minute apology saying that it's off, but I hope not. It will be trasnmitted at TTL 31 -- i.e. just within JIPS (ac.uk) -- unless anyone wants the TTL raised. If so, please let me know your nearest mrouted, and whether you want just the audio, or audio and video. It's meant as a "low key" transmission (without anyone manning the camera, etc). The video will just be of the speaker (slides will **ONLY** be available via the WWW -- not on the video feed). NAME: Richard O. Hundley and Robert H. Anderson, RAND Corporation DATE: Monday 5th December 1994 at 4.15pm (16:15 UTC) TITLE: Security in Cyberspace: an emerging challenge for society As more and more human activities move into cyberspace, they become exposed to a new set of vulnerabilities, that can be exploited by a wide spectrum of "bad actors" for a variety of motives. This seminar discusses questions such as: 1. How serious are the likely threats to different segments of society, both today and in the future, from cyberspace-based attacks? 2. What are the best strategies for achieving security in cyberspace? 3. What roles and missions should various national entities be assigned? 4. Are there specific services and institutions that play such vital roles in society that their protection from cyberspace-based attacks should be of national concern? This presentation does not answer all these questions, but at least attempts to structure the discussion so that meaningful answers can be obtained. This seminar will be multicast (audio and video) on the mbone as part of our multimedia test programme. Further information is available at http://www.cl.cam.ac.uk/mbone/#cl. From rem-conf-request@es.net Mon Dec 05 07:15:57 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <23693-0@osi-west.es.net>; Mon, 5 Dec 1994 04:15:14 +0000 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 5 Dec 1994 12:14:47 +0000 To: Jon Crowcroft cc: Eric Davis , rem-conf@es.net, mice-nsc@cs.ucl.ac.uk Subject: Re: MBONE Music In-reply-to: Your message of "Mon, 05 Dec 94 09:12:15 GMT." <1039.786618735@cs.ucl.ac.uk> Date: Mon, 05 Dec 94 12:13:27 +0000 From: Gordon Joly jon> if then all the tools around (vat,vic,ivs,nv,wb) all promiscuously jon> listend to session messages, and respected the priority of other jon> sessions, we could implement a global backoff by less important sessions jon> when more important ones are live.... Not the tools, more the people. On Tuesday last week, 29 November, MICE sent a seminar from Norway. We had announced this well in advance. Another meeting, not announced in rem-conf or else where (please correct me) seemed to take precedence and we had to cancel the seminar as a result of packet loss. Gordon Joly Email: G.Joly@cs.ucl.ac.uk +441713807934 FAX +441713871397 Computer Science, University College London, Gower St., LONDON WC1E 6BT http://www.cs.ucl.ac.uk/people/gordo/ http://artaids.dcs.qmw.ac.uk:8001/ From rem-conf-request@es.net Mon Dec 05 10:36:56 1994 Received: from apollo.phys.Virginia.EDU by osi-west.es.net via ESnet SMTP service id <25251-0@osi-west.es.net>; Mon, 5 Dec 1994 07:36:29 +0000 Received: by apollo.phys.Virginia.EDU with SMTP (1.37.109.4/16.2) id AA00852; Mon, 5 Dec 94 10:35:25 -0500 To: rem-conf@es.net Subject: unsubscribe Date: Mon, 05 Dec 1994 10:35:21 -0500 From: Lee Cole Smith unsubscribe From rem-conf-request@es.net Mon Dec 05 15:39:51 1994 Received: from relay3.UU.NET by osi-east.es.net via ESnet SMTP service id <23342-0@osi-east.es.net>; Mon, 5 Dec 1994 12:39:15 +0000 Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQxszy25447; Mon, 5 Dec 1994 15:37:59 -0500 Received: from multilink.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Mon, 5 Dec 1994 15:37:50 -0500 Original-Received: from cc:Mail by multilink.multilink.com id AA786669224 Mon, 05 Dec 94 15:13:44 PP-warning: Illegal Received field on preceding line Date: Mon, 05 Dec 94 15:13:44 From: mdigioia@multilink.com Message-Id: <9411057866.AA786669224@multilink.multilink.com> To: rem-conf@es.net Subject: Add to list Please add my email address to the RTP list. mpd@world.std.com mdigioia@multilink.com thanks, /mpd From rem-conf-request@es.net Mon Dec 05 18:20:44 1994 Received: from touchstone.power.net by osi-west.es.net via ESnet SMTP service id <29787-0@osi-west.es.net>; Mon, 5 Dec 1994 15:20:07 +0000 Received: by power.net (Smail3.1.28.1 #11) id m0rEmgp-000syEC; Mon, 5 Dec 94 15:19 PST Date: Mon, 5 Dec 1994 15:19:27 -0800 (PST) From: Elias Levy To: Jon Crowcroft cc: Eric Davis , rem-conf@es.net Subject: Re: MBONE Music In-Reply-To: <1039.786618735@cs.ucl.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 5 Dec 1994, Jon Crowcroft wrote: > > > one way of making this less contentios would be if sd permitted > priorities - then people copuld start up sessions like the IETF > broadcast at high priority, whilst the radio sessions would be lower > > if then all the tools around (vat,vic,ivs,nv,wb) all promiscuously > listend to session messages, and respected the priority of other > sessions, we could implement a global backoff by less important sessions > when more important ones are live.... > Hopefully the Flow Labels in IPv6 (aka IPng) will help with this problem. > ivs, for example, already adapts to loss - it would be trivial to make > it adapt to 'Very Important People's' session messages, and back off > further.... > > then we wouldn't even have to wait for RSVP and CSZ or CBQ routers.... > > jon > > elias@power.net (Elias Levy) PowerNet, Inc. From rem-conf-request@es.net Tue Dec 06 03:01:25 1994 Received: from ibminet.awdpa.ibm.com by osi-west.es.net via ESnet SMTP service id <03307-0@osi-west.es.net>; Tue, 6 Dec 1994 00:00:43 +0000 Received: by ibminet.awdpa.ibm.com (5.61/1.15) id AA06127; Tue, 6 Dec 94 00:06:49 -0800 Received: by ibmpa.awdpa.ibm.com (5.65b(em1)/2.06) id AA06420; Mon, 5 Dec 94 23:58:34 -0800 Received: from cs.nps.navy.mil by ibminet.awdpa.ibm.com (5.61/1.15) id AA06023; Tue, 6 Dec 94 00:03:25 -0800 Received: from trouble.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA23365; Mon, 5 Dec 94 23:57:49 PST Received: by trouble.cs.nps.navy.mil (940715.SGI.52/911001.SGI) for @cs.nps.navy.mil:rem-conf%es.net@ibmpa.awdpa.ibm.com id AA20042; Mon, 5 Dec 94 23:57:47 -0800 From: Your VE info source Message-Id: <9412052357.ZM20033@trouble.cs.nps.navy.mil> Date: Mon, 5 Dec 1994 23:57:47 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: rem-conf%es.net@ibmpa.awdpa.ibm.com Subject: JOURNAL OF VIRTUAL REALITY IN MEDICINE Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 SIG-Advanced Applications, Inc., a major publisher and producer of VR Systems Conferences and Exhibitions, is proud to announce the publication of the JOURNAL OF VIRTUAL REALITY IN MEDICINE. The only journal that will create a forum for the exchange of information for emerging Virtual Reality Technologies as they relate to the field of medicine. The premiere volume of the JOURNAL OF VIRTUAL REALITY IN MEDICINE will present papers covering: -- Telepresence Surgery -- Real-World Applications -- Medical Education -- Telemedicine -- Three-Dimensional Imaging and Robotics -- VR in the Delivery Room -- VR for Individual Physician Training -- Head-Mounted Displays in Laparoscopic Surgery -- New Products and Developments ...and much more is being planned. * Expanded Editorial Board (Partial list as of November 8, 1994) Editor-in-Chief Michael J. Torma, M.D. Chairman, Surgical Services & Institute for Surgical Sciences Presbyterian Hospital of Dallas Rory Stuart Member of Technical Staff, NYNEX Science & Technology Robert J. Greenstein, M.D., FACS Dept. of Surgery, Mt. Sinai School of Medicine, Bronx VA Hospital Baxter J. Garcia, Ph.D. Automated Medical Products Corp., New York, NY Jonathan R. Merril, M.D. Vice President, High Techsplanations William E. Lorensen, Ph.D. General Electric, Research & Development Kevin T. McGovern, Executive Vice President, Cin=8E-Med Anthony Lloyd Vice President, BioControl Systems Col. Richard M. Satava, M.D., FACS General Surgery, Walter Reed Army Center and Advanced BioMedical Technology, and Advanced Research Project Agency (ARPA, Arlington, VA) John P. Brennan, MD OB-GYN, Long Island College Hospital James S. Zinreich, MD, FACS Johns Hopkins Medical School Noshir A. Langrana, M.D. Dept. of Mechanical/Aerospace & Engineering, Rutgers University Christine S. Siegel Hippocrates Project, NYU Medical Center Anthony Reino, M.D. Dept. of Otolaryngology, Mt. Sinai Medical Center Joshua S. Lateiner VOX-L, Inc. Daniel B. Karron, Ph.D. Research Assistant Professor, NYU Medical Center Michael Ferder Dept. of Plastic & Reconstructive Surgery, Montefiore Medical Center, The Albert Einstein College of Medicine Michael Rothschild Assistant Professor, Pediatrics & Otolaryngology, Mt. Sinai School of Medicine Steven I. Becker Medical Director, Surgery Center Michail M. Pankratov Director of Research, New England Medical Center Jack B. Stubbs Principal Scientist, Johnson & Johnson Berisch Strauch, M.D. Professor & Chairman, Plastic Surgery, Montefiore Medical Center Rob Johnston Institute for Defense Analysis Edmond A. Knopp, M.D. MRI Department, NYU Medical Center Werner K. Doyle, M.D. Assistant Professor of Clinical Neurosurgery, NYU School of Medicine Col. Frederick Goeringer NDIS Project Manager, U.S. Army Medical Materials Agency Maj. Donald V. Smith, M.D. Madigan Army Medical Center Still recruiting for Editorial Board. For further information contact: SIG-Advanced Applications, Inc. 1562 First Avenue, Suite 286, New York, NY 10028 Phone: (212) 717-1318 Fax: (212) 861-0588/89 For subscription information, contact Stanley Goldstein at: SIG-ADVANCED APPLICATIONS, INC. 1562 First Avenue, Suite 286, New York, NY 10028 Phone: (212) 717-1318 Fax: (212) 861-0588/89 From rem-conf-request@es.net Tue Dec 06 10:01:56 1994 Received: from europe.std.com by osi-east.es.net via ESnet SMTP service id <10406-0@osi-east.es.net>; Tue, 6 Dec 1994 07:01:32 +0000 Received: from world.std.com by europe.std.com (8.6.8.1/Spike-8-1.0) id KAA16409; Tue, 6 Dec 1994 10:00:17 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA21808; Tue, 6 Dec 1994 10:00:24 -0500 Date: Tue, 6 Dec 1994 10:00:24 -0500 From: mpd@world.std.com (Michael P DiGioia) Message-Id: <199412061500.AA21808@world.std.com> To: rem-conf@es.net Subject: Real-time modem data I am developing a new application protocol to run on TCP that will be able to handle multiplexing many data modems (72 per system) over one LAN to one or more peer systems on the other side of the LAN. I have lots of the same real-time and flow control/Sync issues. Does anyone have any ideas on how to use RTP or other options? /mpd From rem-conf-request@es.net Tue Dec 06 11:12:43 1994 Received: from trystero.radio.com by osi-west.es.net via ESnet SMTP service id <10772-0@osi-west.es.net>; Tue, 6 Dec 1994 08:12:16 +0000 Received: (carl@localhost) by trystero.radio.com (8.6.9/940816.06ccg) id LAA21312; Tue, 6 Dec 1994 11:11:27 -0500 From: Carl Malamud Message-Id: <199412061611.LAA21312@trystero.radio.com> Subject: Radio Stations on Net To: rem-conf@es.net Date: Tue, 6 Dec 1994 11:11:27 -0500 (EST) Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2937 I've noticed some push back to the proposal by Eric Davis to bring IUMA onto the MBONE. There are strong worries about hordes of students with CD players destroying our fragile infrastructure. As many of you may know, my group has spent the last year putting in infrastructure that will do similar things to that which Eric is planning. We've acquired carriage rights to news programs like Monitor Radio and have agreements in place with groups like the Kennedy Center, National Press Club and have credentials with the U.S. Congressional Gallery. When we get back from the IETF, we've been planning to do the final connections to our infrastructure and begin the production of more events. We're going to start with (hopefully) a live broadcast of Handel's Messiah from the Kennedy Center, then move on to turn on gavel-to-gavel coverage of the floor of the U.S. House and Senate, then add a variety of other programming efforts. As always, we will try very hard to make appropriate use of the protocols that we use. As you all know, we tried very hard to set up mirror sites for our FTP data, have worked long and hard on appropriate use of the web, and have always been extremely careful with the MBONE. The fact that we're putting a Kennedy Center broadcast up doesn't mean that we will bulldoze data out to the net. We'll watch the mbone, scale back during periods of congestion and contention, and otherwise do what any of you would do when transmitting data. We realize the MBONE is a fragile infrastructure, but I would really hope that the community would be willing to consider what we are doing as a research experiment just as much as a new release of some software. We're trying to learn what it means to be a station on the Internet and as part of that learning we're going to keep trying new things. There has been a great deal of discussion that if we let Eric do IUMA and us do the Kennedy Center, then every Finn with a CD player will hook up. Its very important to realize that IUMA and Internet Multicasting are *LEGAL*, where as something like Radio Free Vat or a CD Player on the net is quite simply theft of intellectual property. If we're asking how we distinguish between appropriate use and inappropriate use of the MBONE, may I suggest that the first cut ought to be whether the activity is legal? You'll find that very few people have the committment to construct a real source of legal data. Just being legal isn't enough to justify things ... it must also be appropriate, but I think that is certainly one important way to distinguish activities. Please let me know if anybody wants more details on our operation. We've always been an open book ... although as a small non-profit Internet Multicasting would be a paperback. Since we've adopted a "public radio" like programming model, I guess that makes us a boring paperback. Hope you'll join us. ;-) Regards, Carl Malamud From rem-conf-request@es.net Tue Dec 06 12:16:31 1994 Received: from ceres.fokus.gmd.de by osi-west.es.net via ESnet SMTP service id <11306-0@osi-west.es.net>; Tue, 6 Dec 1994 09:16:08 +0000 Received: from ursa.fokus.gmd.de by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Tue, 6 Dec 1994 18:13:55 +0100 X-Mailer: exmh version 1.5.1 12/2/94 To: Carl Malamud cc: rem-conf@es.net From: Henning Schulzrinne Subject: Re: Radio Stations on Net In-reply-to: Your message of "Tue, 06 Dec 94 11:11:27 EST." <199412061611.LAA21312@trystero.radio.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 06 Dec 94 18:14:03 +0100 Sender: schulzrinne@fokus.gmd.de Like any new Internet service, it's a balancing act: provide enough useful content so that people are willing to spend resources (technical, new equipment, software development, personnel at network providers, etc.) to maintain and enhance the service and the infrastructure, without breaking existing services too badly. After all, we WANT people to upgrade from a 64 kb line, we want router vendors to raise multicast on their priority list, etc. This happens if there are interesting content/applications AND if the current infrastructure is just barely insufficient, but good enough to appreciate what you might be able to get with an upgrade that is within reach. Thus, there has to be a continuous 'raising-of-the-bar'. Your project seems to be a good step in that direction. Henning From rem-conf-request@es.net Tue Dec 06 16:37:50 1994 Received: from relay3.UU.NET by osi-west.es.net via ESnet SMTP service id <13532-0@osi-west.es.net>; Tue, 6 Dec 1994 13:37:21 +0000 Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQxtdu25207; Tue, 6 Dec 1994 16:37:16 -0500 Received: from multilink.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Tue, 6 Dec 1994 16:37:05 -0500 Original-Received: from cc:Mail by multilink.multilink.com id AA786759219 Tue, 06 Dec 94 16:13:39 PP-warning: Illegal Received field on preceding line Date: Tue, 06 Dec 94 16:13:39 From: mdigioia@multilink.com Message-Id: <9411067867.AA786759219@multilink.multilink.com> To: brian@lloyd.com CC: rem-conf@es.net Subject: Re: Real-time modem data Brian, I am developing a new application protocol to run on TCP that will be >able to handle multiplexing many data modems (72 per system) over one >LAN to one or more peer systems on the other side of the LAN. > >I have lots of the same real-time and flow control/Sync issues. > >Does anyone have any ideas on how to use RTP or other options? > > I think you are reinventing the wheel. My prior mail message was intended to prompt responses/replies on any specific RFC (or working group) or protocol that exists for doing this kind of application. Your one line reply suggests that you know or may have an idea of a wheel I can use without indicating anything else. Is this due to not knowing the details of what I am attempting to do? Is it to be assumed that the wheel I am reinventing is RTP itself? I would like to see RTP made general enough to handle my application. As it is currently defined, it expects to be on the end systems where the data source and sink is located, e.g., microphones, cameras, or some other form of data. It includes such things as "type of audio encoding" which is not available from the output of voice, data, or voice and data modems. I am not able to attend the meeting this week but hope we can use this as a basis for creating a more useful RTP protocol. ******* >I am developing a new application protocol to run on TCP that will be >able to handle multiplexing many data modems (72 per system) over one >LAN to one or more peer systems on the other side of the LAN. > >I have lots of the same real-time and flow control/Sync issues. >Does anyone have any ideas on how to use RTP or other options? ******** /mpd From rem-conf-request@es.net Tue Dec 06 16:38:22 1994 Received: from relay3.UU.NET by osi-west.es.net via ESnet SMTP service id <13542-0@osi-west.es.net>; Tue, 6 Dec 1994 13:37:43 +0000 Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQxtdu25218; Tue, 6 Dec 1994 16:37:17 -0500 Received: from multilink.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Tue, 6 Dec 1994 16:37:06 -0500 Original-Received: from cc:Mail by multilink.multilink.com id AA786761618 Tue, 06 Dec 94 16:53:38 PP-warning: Illegal Received field on preceding line Date: Tue, 06 Dec 94 16:53:38 From: mdigioia@multilink.com Message-Id: <9411067867.AA786761618@multilink.multilink.com> To: jim@tadpole.com CC: rem-conf@es.net Subject: Re: Real-time modem data Jim, >Been there, done that, works with TCP just fine... This was not my question, sorry if I led you to think I asked the question - Can I communicate modem output data over a TCP connection? One can setup a TCP path and send any data over that path. Let me restate my question. It has two parts as follows: 1. Is the RTP working group the best list to address RTP related issues with modem data as well as audio, video and simulated data. Or does someone know a better WG? 2. Does anyone know where I can find any existing protocols I can start with, not to re-invent the wheel and to build on what already exists. Mostly because, just sending/receiving one modem's data is less of a challange than doing for some large number (more than 50) all capable of operation at 14,400 BPS. Akin to other real-time data, there are lots of sync issues, control issues, and in addition modem state and signal issues. /mpd From rem-conf-request@es.net Wed Dec 07 03:11:44 1994 Received: from smtp.tele.fi by osi-west.es.net via ESnet SMTP service id <18601-0@osi-west.es.net>; Wed, 7 Dec 1994 00:11:13 +0000 Received: from norppa.dat.tele.fi by smtp.tele.fi (5.0/SMI-SVR4/tele 1.0) id AA09453; Wed, 7 Dec 94 10:06:47 +0200 Received: from localhost (pjj@localhost) by norppa.dat.tele.fi (8.6.5/8.6.5) id KAA02403; Wed, 7 Dec 1994 10:10:50 +0200 Date: Wed, 7 Dec 1994 10:10:50 +0200 Message-Id: <199412070810.KAA02403@norppa.dat.tele.fi> To: CASNER@ISI.EDU From: Petri Jokela Cc: MBONE@ISI.EDU, rem-conf@es.net Subject: Re: No "Jazz stars" sessions, please In-Reply-To: Stephen Casner's message at 2 December 94 14:21:47 PST References: <786406907.0.CASNER@XFR.ISI.EDU> content-length: 835 Stephen Casner has written on 2 December 94 14:21:47 >This note is to pjj@norppa.dat.tele.fi in particular, but a general >reminder to the community also seems warranted. > > >Please do not create sessions like the "Jazz stars" session you have >now. It would be nice if everyone could send out the kind of music >that they like, but the bandwidth available on the MBone is very >limited. If there is too much traffic, all the users suffer. I apologize my beahaviour. I was locally first locally testing our ATM network, but I didn't realize free Mbone bandwidth is so limited at the moment. I'll use ttl's much below 32, so its' safe to run sessions locally, isn't it? -- Petri Jokela Telecom Finland Tel. +358 2040 72210 P.O.X 228 Cellular +358 49 732731 33101 Tampere Fax. +358 2040 72669 From rem-conf-request@es.net Wed Dec 07 03:23:37 1994 Received: from icsia.ICSI.Berkeley.EDU by osi-west.es.net via ESnet SMTP service id <18675-0@osi-west.es.net>; Wed, 7 Dec 1994 00:23:10 +0000 Received: from icsid.ICSI.Berkeley.EDU (whd@icsid.ICSI.Berkeley.EDU [128.32.201.59]) by icsia.ICSI.Berkeley.EDU (8.6.8/HUB+V8$Revision: 1.22 $) with ESMTP id AAA16596; Wed, 7 Dec 1994 00:23:02 -0800 From: whd@ICSI.Berkeley.EDU (Wieland Holfelder) Received: (whd@localhost) by icsid.ICSI.Berkeley.EDU (8.6.8/1.8) id AAA16483; Wed, 7 Dec 1994 00:22:58 -0800 Message-Id: <199412070822.AAA16483@icsid.ICSI.Berkeley.EDU> Subject: PT values in RTP/RTCP To: rem-conf@es.net (Remote Conferencing) Date: Wed, 7 Dec 1994 00:22:56 -0800 (PST) Cc: casner@isi.edu X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4598 Hi everybody, after listening to today's avt meeting and Steve Casner's comments about the Packet Type numbers of RTCP packets I was wondering whether we couldn't do even better in terms of distinguishing between RTP and RTCP packets. This feature would be helpful if we think about storing RTP and RTCP packets in a file (e.g. for a recording and playback application which is what I try to do). Since a while ago there was already a discussion about spending one more bit for this purpose and the majority didn't want that bit, I looked at the spec (draft-ietf-avt-rtp-06.txt) again to find a way that would enable us to distinguish between RTP and RTCP packets without spending this extra bit. Here is what I found: 5.1 The RTP header has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PT=Payload Type 6.3 SR: Sender report 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T=2|P| RC | PT=RTCP_SR=0 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PT=Packet Type 6.4 RR: Receiver report 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T=2|P| RC | PT=RTCP_RR=1 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PT=Packet Type The spec says that on the session port we always get first either a sender or a receiver report before we get any other RTCP packet. Therefore we know that if we have these packets in a file (rtp and rtcp all together) and we read one rtp/rtcp packet after another >from this file, that we would always get one of the three packets above. (Given that we would process all control packets after we read a SR or RR) So if we would make the Packet Type field in the RTCP_SR and RTCP_RR packets one bit smaller (e.g. reserve the bit and set it to 0, see comments below) then Payload Type in RTP and Packet Type in RTCP packets would be lined up and easy to analyze. And, in fact, it doesn't look like we would really need 255 Packet types (right now we only use 6 types: RTCP_SR, RTCP_RR, RTCP_SDES, RTCP_BYE, RTCP_FMT, RTCP_APP). Anyway, all we would need to do now to be able to distinguish between RTP and RTCP packets would be to spend 2 values (for RTCP_SR and RTCP_RR) in the payload format space of 2**7=128. We wouldn't have to spend a whole bit (which would mean spend 64 payload types) but only two payload types out of 128 with the gain to be able to distinguish between RTP and RTCP packets (which is a nice side effect of stacking RTCP packets). The bit we reserved in the RTCP header (see above) could be used to mark all RTCP packets following a SR or RR as RTCP packets. It should be 0 for the SR or RR message and could then be set to 1 for all following control packets belonging to this SR or RR. Ok, so how can we find out when the control packets end without assuming anything about the marker bit in RTP packets? Well, if we keep in mind that this is only an issue when reading from a file, the application recording the rtp/rtcp packets had to make sure that it stores all RTCP packets that belong to a SR or RR directly after their SRs or RRs and then it could store the first 32 bits of a SR or RR header with the reserved bit set to one as sort of an "end of control message". With the approach of Steve Casner, which would use PT numbers of 201 for RTCP_SR in RTCP headers we could only assume that a packet is not a RTP but a RTCP packet as long as the Payload Type 74 with the Marker bit set to one is not used (74 = 201 - 127) but we couldn't really be certain. What do you think? -- Wieland ------------------------------------------------------------------------------- Wieland Holfelder International Computer Science Institute Email: whd@icsi.berkeley.edu 1947 Center Street Suite 600 Fax : +1-510-642-6865 Berkeley, CA 94704-1198 Phone: +1-510-642-4274 Ext. 302 URL: http://www.icsi.berkeley.edu/~whd ------------------------------------------------------------------------------- From rem-conf-request@es.net Wed Dec 07 09:50:20 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <03262-0@osi-west.es.net>; Wed, 7 Dec 1994 06:48:40 +0000 Received: from Mesl_Mail.WRC-MESL.XEROX.xns by alpha.xerox.com via XNS id <14616(2)>; Wed, 7 Dec 1994 06:48:19 PST X-NS-Transport-ID: 08003700646A2D43329D Date: Wed, 7 Dec 1994 06:48:10 PST From: Meng_Lean.WRC-MESL@xerox.com Subject: Re: SPARC 5s and VideoPIX In-Reply-to: <9412010409.AA11904@hibp.ecse.rpi.edu> To: stewart@hibp6.ecse.rpi.edu cc: CXG@slac.stanford.edu, rem-conf@es.net Reply-to: meng.wrc-mesl@xerox.com Message-ID: <"7-Dec-94 9:48:02".*.Meng_Lean.wrc-mesl@Xerox.com> Importance: Normal I have a SparcStation 20 running SuunOS 4.1.3 ver b. I ran into tha same problem running the install_unbundle script from CD-ROM. As you suggested, I tried running the vfc.INSTALL script directly and now have a new message. It cannot locate command "modload". Suggestions? Thanks. From rem-conf-request@es.net Wed Dec 07 10:41:49 1994 Received: from trystero.radio.com by osi-east.es.net via ESnet SMTP service id <29321-0@osi-east.es.net>; Wed, 7 Dec 1994 07:41:26 +0000 Received: (carl@localhost) by trystero.radio.com (8.6.9/940816.06ccg) id KAA01350 for rem-conf@es.net; Wed, 7 Dec 1994 10:36:24 -0500 From: Carl Malamud Message-Id: <199412071536.KAA01350@trystero.radio.com> Subject: Why IMS does music on IETF-TV To: rem-conf@es.net Date: Wed, 7 Dec 1994 10:36:24 -0500 (EST) Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1797 Some of you may have noticed that we're spinning disks in between IETF sessions on IETF Channel 1. Nobody has pointed out the apparent contradiction between the fact that we play music and the fairly harsh words I've had for other people playing music, but I felt that this does deserve explanation. Internet Multicasting Service believes we have BMI/ASCAP licensing to play music. The reason for this is that we fall into the legal category of a "Public Telecommuications Entity." PTEs are defined as non-profit news organizations and the category was originally designed to cover public radio stations. Under a decision of the copyright royalty tribunal in the U.S., we are entitled, after paying roughly $1000 per year in licensing fees, to use BMI/ASCAP material. We sent our checks in and both remain uncashed by the licensing groups. They maintain that we aren't a radio station. We believe (and our attorney is the former General Counsel for National Public Radio who negotiated the tribunal decision) that BMI and ASCAP don't have a choice on the matter and that we clearly fall into the PTE category. They believe otherwise. ;-) We're trying hard to get the attornies from the two groups into our studio to prove to them that the MBONE and the Internet is not really a threat, particularly at 8 khz transmission. We're trying to convince them that this will in fact be no different than radio: people listen, then go buy the album rather than store the data on disk. CD is a very efficient storage structure for 48 khz data, whereas /tmp has occasional problems. I realize this doesn't handle international issues, but lets take this one step at a time. The point is that we are putting our money (such as it is) into the effort of getting music on the network. Carl From rem-conf-request@es.net Wed Dec 07 10:48:51 1994 Received: from comm.cpd.tandem.com by osi-east.es.net via ESnet SMTP service id <29490-0@osi-east.es.net>; Wed, 7 Dec 1994 07:48:20 +0000 Received: by comm.Tandem.COM (4.12/4.5) id AA22329; 7 Dec 94 07:47:59 -0800 Date: 7 Dec 94 07:46:00 -0800 From: KIM_ANDY@tandem.com Message-Id: <199412070747.AA22329@comm.Tandem.COM> To: rem-conf@es.net Subject: unsubscribe From rem-conf-request@es.net Wed Dec 07 13:50:14 1994 Received: from rx7.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <02869-0@osi-west.es.net>; Wed, 7 Dec 1994 10:47:55 +0000 Received: by rx7.ee.lbl.gov for rem-conf@es.net (5.65/1.44r) id AA18342; Wed, 7 Dec 94 10:50:51 -0800 Message-Id: <9412071850.AA18342@rx7.ee.lbl.gov> To: ietf@ietf.cnri.reston.va.us Cc: rem-conf@es.net Subject: vic use during ietf video feed Date: Wed, 07 Dec 94 10:50:50 PST From: Van Jacobson I'd like to get an opinion from people watching the ietf video feed on the mbone. Steve McCanne put a tremendous effort into getting the vic release out a week before ietf so that we might have a chance of using it for some of the meeting. (Old timers might remember that the first, binary-only, release of nv happened <24 hours before the Dec.'92 ietf where it was first used so we thought a source+binary release a week before the meeting, while not optimal, would be acceptable.) There were two reasons for doing this: - vic is the first complete (so far as we know) implementation of rtpv2 so it gives us a chance to try out the monitoring & diagnostic capabilities of rtpv2 in a large-scale conference. - vic gives a *much* higher framerate than nv for the same bandwidth, quality & loss tolerance. (In the one try we got to do during the IDMR session, nv was giving .2-.3 frames/sec @ 100kb/s. We switched to vic/h261 and got 8-10 frames/sec at the same bandwidth, a factor of 30 improvement. Qualitatively, the difference was between a slow slide show & real, full-motion video. Carl Malamud & the Internet Multicasting Service who are doing the feed (& doing a great job) have said they'd be glad to do whatever the viewer community wants. Steve Casner has been very reluctant to allow the test. I don't understand most of the reasons given for this but the one technical objection seemed to be the lack of a 'recording' facility for rtpv2 sessions. So, I've put the source of an rtpv2 recording app in ftp://ftp.ee.lbl.gov/conferencing/vic/rtp_record.cc The rules to build this are already in the vic makefile so you should be able to just stick this source in your vic directory & type "make rtp_record". So this is a question for the audience: Would you mind if we used vic rtpv2 format for some of the ietf sessions? I.e., would a 30-times improvement in framerate & much better diagnostic capability bother you? (And if so, why?) Thanks. - Van From rem-conf-request@es.net Wed Dec 07 15:29:25 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <03942-0@osi-west.es.net>; Wed, 7 Dec 1994 12:27:57 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-19) id ; Wed, 7 Dec 1994 12:27:48 -0800 Posted-Date: Wed 7 Dec 94 12:26:38 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Wed, 7 Dec 94 12:26:39 PST Date: Wed 7 Dec 94 12:26:38 PST From: Stephen Casner Subject: Re: vic use during ietf video feed To: van@ee.lbl.gov, IETF@ietf.cnri.reston.va.us Cc: rem-conf@es.net Message-Id: <786831998.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9412071850.AA18342@rx7.ee.lbl.gov> Mail-System-Version: Van, > Steve Casner has been very reluctant to allow the test. This is just not true. Having put a lot of effort into RTP myself, I want very much to see a test of RTPv2. That's why I suggested that there be a parallel transmission of video using vic during all of the plenary sessions. I made this suggestion last week and Steve McCanne said he thought it was a good plan. I thought this would give a good test of vic without causing hardship for non-experts who may be watching using software setups that were done for them by experts who are now here at IETF, or for those who had set up scripts to record. During previous IETF multicasts in which I had more personal involvement, we were blasted on this issue. The plan I suggested was to create a separate sd session for the parallel vic test. My complaint was that in the IDMR test, the format was changed even though the session indicated nv format. This caused trouble for at least one person who needed to know how to manually start vic in order to receive the video, which in turn caused a small disruption of the session when he (not unreasonably) wrote on the wb session to ask for instructions. It is terrific that vic is now released, and doubly terrific that it is a source release. Thanks, too, for the RTPv2 recorder you've just made. For the next IETF, I hope to see all of the video *and audio* is sent in RTPv2. In fact, ditto for other events before then. In particular, I had set up to record the AVT session yesterday afternoon, so I appreciate the fact that Carl Malamud's crew used the nv encoding for that session. But I don't need the grief, and I won't be in a location to see any of the transmissions from this point on anyway, so I don't care what format is used for any of the remaining transmissions. -- Steve ------- From rem-conf-request@es.net Wed Dec 07 18:21:15 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <01054-0@osi-west2.es.net>; Wed, 7 Dec 1994 18:15:58 -0800 Received: from cdcnet.uniandes.edu.co by osi-west.es.net via ESnet SMTP service id <04116-0@osi-west.es.net>; Wed, 7 Dec 1994 12:36:57 +0000 Received: from ucauca.edu.co (ucauca.coldapaq.net.co) by cdcnet.uniandes.edu.co (4.1/SMI-4.1) id AA25679; Wed, 7 Dec 94 15:34:49 EST Received: by ucauca.edu.co (4.1/SMI-4.1) id AA25728; Wed, 7 Dec 94 15:36:32 CDT Date: Wed, 7 Dec 1994 15:36:32 -0300 (CDT) From: Aplicaciones Telematicas To: rem-conf@es.net Cc: MBONE@ISI.EDU Subject: Real-Time voice on internet? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Outgroup research on Real-time voice transmission on Internet. We know something about particular real time aplications as vat.nevot, etc; these aplications use anyone protocols such as RTP, ST-II...; these protocols are standards for the aplications from real time ? We should like to know the general architecture of these systems. What aplications are RTP-based? RTP is an standard or is an work in progress ? =========================================================================== Javier Andrade Sarria | Investigacion Aplicaciones Telematicas Cesar Antonio Ibarguen | Calle 1AN #11-42 | Universidad del Cauca Popayan | E-mail : telapp@atenea.ucauca.edu.co Colombia , South America | | Facultad de Ingenieria Electronica | Universidad del Cauca =========================================================================== From rem-conf-request@es.net Wed Dec 07 18:25:55 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <01054-1@osi-west2.es.net>; Wed, 7 Dec 1994 18:16:03 -0800 Received: from rs6a.wln.com by osi-west.es.net via ESnet SMTP service id <04528-0@osi-west.es.net>; Wed, 7 Dec 1994 13:17:25 +0000 Received: from PORT-031.DIAL.NET.NYU.EDU by rs6a.wln.com (AIX 3.2/UCB 5.64/4.06) id AA88343; Wed, 7 Dec 1994 13:15:44 -0800 Date: Wed, 7 Dec 94 16:18:07 EST From: delibero@wln.com Subject: To: rem-conf@es.net X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe From rem-conf-request@es.net Wed Dec 07 18:30:57 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <01054-2@osi-west2.es.net>; Wed, 7 Dec 1994 18:16:09 -0800 Received: from fnpspa.fnal.gov by osi-west.es.net via ESnet SMTP service id <04994-0@osi-west.es.net>; Wed, 7 Dec 1994 13:53:16 +0000 Received: from fnvdeo.fnal.gov by fnpspa.fnal.gov via SMTP (931110.SGI/930416.SGI) for rem-conf@es.net id AA24125; Wed, 7 Dec 94 15:53:05 -0600 Received: by fnvdeo.fnal.gov (931110.SGI/930416.SGI) for @fnpspa.fnal.gov:rem-conf@es.net id AA11481; Wed, 7 Dec 94 15:53:04 -0600 Date: Wed, 7 Dec 94 15:53:04 -0600 From: spkr3@fnvdeo.fnal.gov (Speaker 3) Message-Id: <9412072153.AA11481@fnvdeo.fnal.gov> To: rem-conf@es.net Subject: mbone conference We will be holding an mbone video/audio conference tomorrow. I have already created the conference on SD. It is called CMS SW Group, using port/id video: 34885/20770 audio: 62754/37461 and will last from 10:00 to 18:00 CST. I apologize for the late notice, we are new at this game. (IP address of originating machine is: FNVDE2 131.225.8.61 Thanks, Irwin Gaines From rem-conf-request@es.net Wed Dec 07 18:39:27 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <01054-3@osi-west2.es.net>; Wed, 7 Dec 1994 18:16:14 -0800 Received: from ietf.cnri.reston.va.us by osi-west.es.net via ESnet SMTP service id <05009-0@osi-west.es.net>; Wed, 7 Dec 1994 13:57:20 +0000 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11520; 7 Dec 94 16:50 EST To: IETF-Announce:; From: mwalnut@CNRI.Reston.VA.US cc: rem-conf@es.net Subject: IETF ON-SITE ADDITION: AVT Session Date: Wed, 07 Dec 94 16:50:10 -0500 Sender: mwalnut@CNRI.Reston.VA.US Message-ID: <9412071650.aa11520@IETF.CNRI.Reston.VA.US> There will be a second session of the AVT Working Group on Thursday morning in the Terrace Room. It will not be multicast. Megan From rem-conf-request@es.net Wed Dec 07 18:52:06 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <01054-4@osi-west2.es.net>; Wed, 7 Dec 1994 18:16:19 -0800 Received: from jarrah.itd.adelaide.edu.au by osi-west.es.net via ESnet SMTP service id <05619-0@osi-west.es.net>; Wed, 7 Dec 1994 14:38:56 +0000 Received: by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU+NF/UA-5.28) id AA06473; Thu, 8 Dec 1994 09:07:01 +1030 Message-Id: <9412072237.AA06473@jarrah.itd.adelaide.edu.au> To: Van Jacobson Cc: ietf@IETF.CNRI.Reston.VA.US, rem-conf@es.net Subject: Re: vic use during ietf video feed In-Reply-To: Your message of "Wed, 07 Dec 1994 10:50:50 PST." <9412071850.AA18342@rx7.ee.lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 08 Dec 1994 09:06:59 +1030 From: Mark Prior So this is a question for the audience: Would you mind if we used vic rtpv2 format for some of the ietf sessions? I.e., would a 30-times improvement in framerate & much better diagnostic capability bother you? (And if so, why?) Thanks. While it doesn't affect me personally (I'm here at the IETF rather in my office and I'm not recording the sessions at home) I would have thought that the best method of performing the test is to run vic in parallel to nv during the plenary sessions where the two streams come >from the same session. This doesn't disenfranchise those people who for whatever reason can't change to vic while still providing data >from vic. It also provides an opportunity to directly compare the performance of vic v's nv. Mark. From rem-conf-request@es.net Wed Dec 07 19:08:34 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <01054-5@osi-west2.es.net>; Wed, 7 Dec 1994 18:16:25 -0800 Received: from wizard.gsfc.nasa.gov by osi-west.es.net via ESnet SMTP service id <05628-0@osi-west.es.net>; Wed, 7 Dec 1994 14:40:18 +0000 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA11329; Wed, 7 Dec 94 17:39:03 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9412072239.AA11329@wizard.gsfc.nasa.gov> Subject: Re: vic use during ietf video feed To: van@ee.lbl.gov (Van Jacobson) Date: Wed, 7 Dec 1994 17:39:02 -0500 (EST) Cc: ietf@IETF.CNRI.Reston.VA.US, rem-conf@es.net In-Reply-To: <9412071850.AA18342@rx7.ee.lbl.gov> from "Van Jacobson" at Dec 7, 94 10:50:50 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1617 Van, > Carl Malamud & the Internet Multicasting Service who are doing > the feed (& doing a great job) have said they'd be glad to do > whatever the viewer community wants. Steve Casner has been very > reluctant to allow the test. I don't understand most of the > reasons given for this but the one technical objection seemed to > be the lack of a 'recording' facility for rtpv2 sessions. So, > I've put the source of an rtpv2 recording app in > ftp://ftp.ee.lbl.gov/conferencing/vic/rtp_record.cc > The rules to build this are already in the vic makefile so you > should be able to just stick this source in your vic directory & > type "make rtp_record". Could a binary for rtp_record be added, at least for Sun? > So this is a question for the audience: Would you mind if we > used vic rtpv2 format for some of the ietf sessions? I.e., would > a 30-times improvement in framerate & much better diagnostic > capability bother you? (And if so, why?) Thanks. The sd entry should indicate vic is being used. I was trying to watch the IDMR session with nv with no success until someone squibbled on the whiteboard about using vic. I then switched to using vic. Strictly qualitatively, the nv sessions I have watched have seemed much less blocky and the overhead slides have been much more readable than the IDMR vic session. If the slides are made available via the whiteboard (which doesn't seem to be the case with most sessions I have watched), this is not a major issue. All in all, I don't mind experimenting with vic as long as it's known in advance (through mail and sd). > - Van -Bill From rem-conf-request@es.net Wed Dec 07 19:22:33 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <01054-6@osi-west2.es.net>; Wed, 7 Dec 1994 18:16:30 -0800 Received: from lhc.nlm.nih.gov by osi-west.es.net via ESnet SMTP service id <06102-0@osi-west.es.net>; Wed, 7 Dec 1994 15:03:24 +0000 Received: from billings.csb (billings.nlm.nih.gov) by nlm.nih.gov (4.1/SMI-4.0) id AA08384; Wed, 7 Dec 94 18:03:16 EST Received: by billings.csb (5.0/SMI-SVR4) id AA16998; Wed, 7 Dec 1994 18:04:33 +0500 Date: Wed, 7 Dec 1994 18:04:33 +0500 From: rodgers@nlm.nih.gov (R. P. C. Rodgers, M.D.) Message-Id: <9412072304.AA16998@billings.csb> To: mbone@isi.edu, rem-conf@es.net Subject: Summary report about Oct. WWW Conference multicast is available Content-Length: 716 Dear MBONE Colleagues, We have created a report summarizing our MBONE multicasting experiences at the Second International World-Wide Web Conference in Chicago in October 1994. A number of people had expressed interest in seeing this report. The current version of the report is being offered on HyperDOC, the NLM's WWW server, and can be found at: http://www.nlm.nih.gov/reports.dir/multicasting.dir/report.html I hope that you have comfortable access to a solid Web client. Lack of time will prevent us from offering the report in any other format. Thanks to those of you who participated in the technical preparations, the multicast itself, and the subsequent participant survey. Cheerio, Rick Rodgers From rem-conf-request@es.net Wed Dec 07 19:38:45 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <01054-7@osi-west2.es.net>; Wed, 7 Dec 1994 18:16:35 -0800 Received: from exxilon.xx.rmit.EDU.AU by osi-west.es.net via ESnet SMTP service id <07978-0@osi-west.es.net>; Wed, 7 Dec 1994 17:09:49 +0000 Received: (richard@localhost) by exxilon.xx.rmit.EDU.AU (8.6.9/8.6.4/ram5) id MAA22438; Thu, 8 Dec 1994 12:02:32 +1100 From: "Richard A. Muirden" Message-Id: <199412080102.MAA22438@exxilon.xx.rmit.EDU.AU> Subject: Re: No "Jazz stars" sessions, please To: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Thu, 8 Dec 1994 12:02:32 +1100 (EDT) Cc: CASNER@ISI.EDU, berc@src.dec.com, rem-conf@es.net In-Reply-To: <421.786534553@cs.ucl.ac.uk> from "Mark Handley" at Dec 4, 94 09:49:13 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1157 > It's an interesting cultural phenomena that people will listen to PCM > audio on the Mbone, when for very little money they can but a cheap > radio (if they don't already have one) and get much better quality and > more choice! There's something really _neat_ about listening in on someone else's radio. I remember some months ago the guy from Atlanta was pumping their radio station out. It was boring music, but just hearing the tempratures and so on for the Atlanta area was something else. Besides we get NO reception in this office thanks to all the machines around here generating interference. However I can live without mbone music, I just pump up my CD player :) by the way, that jazz stars being 'stuck' was er.... an interesting thing :-) Anyway this is off the topic of the mailing lists so I'll say no more. cheers, richard -- Richard A. Muirden, Sys. Admin |Fan of Shostakovich, "Star Trek" and the Boeing Mailto: richard@rmit.EDU.AU |777 (launch: May 15, 1995 - United Airlines). Phone: (+61 3) 660 3814 |I created alt.fan.shostakovich! Fly: UA,QF,WN http://www.rmit.edu.au/richard |Can *YOU* beat my 99 Shost CD's? :-) From rem-conf-request@es.net Wed Dec 07 19:51:37 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <01211-0@osi-west2.es.net>; Wed, 7 Dec 1994 18:44:36 -0800 Received: from trystero.radio.com by osi-west.es.net via ESnet SMTP service id <08853-0@osi-west.es.net>; Wed, 7 Dec 1994 18:44:13 +0000 Received: (carl@localhost) by trystero.radio.com (8.6.9/940816.06ccg) id VAA06910; Wed, 7 Dec 1994 21:42:44 -0500 From: Carl Malamud Message-Id: <199412080242.VAA06910@trystero.radio.com> Subject: Re: vic use during ietf video feed To: mrp@itd.adelaide.edu.au (Mark Prior) Date: Wed, 7 Dec 1994 21:42:44 -0500 (EST) Cc: van@ee.lbl.gov, ietf@IETF.CNRI.Reston.VA.US, rem-conf@es.net In-Reply-To: <9412072237.AA06473@jarrah.itd.adelaide.edu.au> from "Mark Prior" at Dec 8, 94 09:06:59 am Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1168 We're going to try and run simulatneous nv/vic feeds out of the Thursday night plenary. BTW, sorry that we were unable to provide a repeat play function in the evening for those of you in other time zones ... we're doing the whole operation with 4.5 people and just don't have the cycles to prepare, advertise, and execute. Carl According to Mark Prior: > > So this is a question for the audience: Would you mind if we > used vic rtpv2 format for some of the ietf sessions? I.e., would > a 30-times improvement in framerate & much better diagnostic > capability bother you? (And if so, why?) Thanks. > > While it doesn't affect me personally (I'm here at the IETF rather in > my office and I'm not recording the sessions at home) I would have > thought that the best method of performing the test is to run vic in > parallel to nv during the plenary sessions where the two streams come > from the same session. This doesn't disenfranchise those people who > for whatever reason can't change to vic while still providing data > from vic. It also provides an opportunity to directly compare the > performance of vic v's nv. > > Mark. > From rem-conf-request@es.net Wed Dec 07 23:42:29 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <01690-0@osi-west2.es.net>; Wed, 7 Dec 1994 23:14:01 -0800 Received: from ceres.fokus.gmd.de by osi-west.es.net via ESnet SMTP service id <10622-0@osi-west.es.net>; Wed, 7 Dec 1994 23:13:29 +0000 Received: from ursa.fokus.gmd.de by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Thu, 8 Dec 1994 08:11:24 +0100 X-Mailer: exmh version 1.5.1 12/2/94 To: Aplicaciones Telematicas cc: rem-conf@es.net From: Henning Schulzrinne Subject: Re: Real-Time voice on internet? In-reply-to: Your message of "Wed, 07 Dec 94 15:36:32 -0300." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 08 Dec 94 08:11:47 +0100 Sender: schulzrinne@fokus.gmd.de > > Outgroup research on Real-time voice transmission on Internet. We know > something about particular real time aplications as vat.nevot, etc; these > aplications use anyone protocols such as RTP, ST-II...; these protocols > are standards for the aplications from real time ? > We should like to know the general architecture of these systems. > What aplications are RTP-based? See the WWW page on RTP on my home page for a more-or-less up-to-date listing and further references. > RTP is an standard or is an work in progress ? Both :-). While details may still change in the next few days/weeks, we intend to submit a slightly modified version of the current draft for last call and consideration as a proposed standard. > > > =========================================================================== > Javier Andrade Sarria | Investigacion Aplicaciones Telematicas > Cesar Antonio Ibarguen | > ------- Henning Schulzrinne email: hgs@fokus.gmd.de GMD-Fokus phone: +49 30 25499 182 ; Wed, 7 Dec 1994 23:24:40 -0800 Received: from brolga.cc.uq.oz.au by osi-west.es.net via ESnet SMTP service id <10698-0@osi-west.es.net>; Wed, 7 Dec 1994 23:23:30 +0000 Received: from cc.uq.oz.au by brolga.cc.uq.oz.au id <10332-0@brolga.cc.uq.oz.au>; Thu, 8 Dec 1994 17:23:01 +1000 To: mbone@isi.edu, rem-conf@es.net Subject: Anaesthesia/Mbone demonstration, Friday 9th December, 9:30-11:30 (GMT+10) Date: Thu, 8 Dec 1994 17:23:01 +1000 From: George Michaelson Sender: G.Michaelson@cc.uq.oz.au Message-ID: <"brolga.cc.uq:103350:941208072307"@cc.uq.oz.au> The University of Queensland division of Anaesthesiology & Intensive care are demonstrating MBONE to their potential funding body (the Qld Health dept) to try and get a distance teaching pilot project off the ground. We intend shipping vic (ivs) format video at under 100kbs, with a ttl of 63 so it stays onshore. PCM2 audio and whiteboard will be at ttl 127 to get to the world. The times are: 9-30am to 11-30am (localtime) 11-30pm Thus, 8th to 1-30am Fri 9th (GMT) We hope to have input from NYU, and would welcome directed presence by persons interested in medical informatics, distance education and multicasting when suitable moments arise. Sorry about short notice, the programme was moved from an earlier timeslot and I was lax in registering my intent. Since IETF etc are coming onshore and the video stream is not escaping, I hope there will not be a problem. (if there is no contention I will raise video ttl to <127 if requested) -George From rem-conf-request@es.net Thu Dec 08 01:51:23 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <02377-0@osi-west2.es.net>; Thu, 8 Dec 1994 01:18:47 -0800 Received: from cs.tut.fi by osi-west.es.net via ESnet SMTP service id <11707-0@osi-west.es.net>; Thu, 8 Dec 1994 01:17:49 +0000 Received: from isosotka.cs.tut.fi (mit@isosotka.cs.tut.fi [130.230.17.14]) by cs.tut.fi (8.6.9/8.6.4) with ESMTP id LAA13039; Thu, 8 Dec 1994 11:20:36 +0200 From: Tsokkinen Mikko Received: (mit@localhost) by isosotka.cs.tut.fi (8.6.8/8.6.4) id LAA05019; Thu, 8 Dec 1994 11:20:34 +0200 Date: Thu, 8 Dec 1994 11:20:34 +0200 Message-Id: <199412080920.LAA05019@isosotka.cs.tut.fi> To: Toerless Eckert Cc: rem-conf@es.net Subject: Re: SunVideo question In-Reply-To: <199411290853.AA12891@faui43.informatik.uni-erlangen.de> References: <199411290853.AA12891@faui43.informatik.uni-erlangen.de> Toerless Eckert writes: >Hi > >I was wondering if someone on this list could comment the following observation. >Upon using the SunVideo board with solaris 2.4 on a ss20/612 a message >is printed, telling me that "rtvc: DMA mode is not supported in this version >of the hardware". I suppose this means that the SunVideo board is suspected >to be able to do DMA mode but that this won't work with the board i have. >I'd like to know if other people have made the same observation and >what kind of throughput can be achieved with the SunVideo board (maybe >this may be used as an indication if DMA is enabled or not). I have SS20/50 running Solaris2.3. I don't get any errors about the DMA. I suspect it does not work with 60 MHz processors. >The following table contains the throughput i could measure with the >SunVideo program that comes with solaris 2.4. The maximum throughput over >the bus seem to be 3.6 MByte/sec (for uncompressed RGB color) and this doesn't >look very much like DMA to me (i.e.: the old VideoPix graphics board that >surely had no DMA would achieve the same throughput). The SunVideo program shows the maximum throughput using 768x576 PAL and direct output without local display is around 40 Mbps (or 5 MBps). The frame rate is around 4. >I wanted to buy another couple of SunVideo boards, but if this could mean for >example that buying now would give me yet another board without DMA and >two month later a board capable of DMA would be available, i'd better wait. I cannot comment whether there will be a new version. I suspect your card works just fine in a 50 or 512 machine. Mikko Tsokkinen Digital Media Institute, Tampere University of Technology Research Assistant - Project FASTER Distributed Multimedia Applications over ATM-Network From rem-conf-request@es.net Thu Dec 08 04:35:34 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <02980-0@osi-west2.es.net>; Thu, 8 Dec 1994 04:25:01 -0800 Received: from next2.lirmm.fr by osi-west.es.net via ESnet SMTP service id <13307-0@osi-west.es.net>; Thu, 8 Dec 1994 04:24:12 +0000 Received: from localhost (mnanard@localhost) by next2.lirmm.fr (8.6.4/8.6.4) id NAA06666; Thu, 8 Dec 1994 13:49:58 +0100 Date: Thu, 8 Dec 1994 13:49:58 +0100 From: Marc Nanard Message-Id: <199412081249.NAA06666@next2.lirmm.fr> Original-Received: by NeXT.Mailer (1.87.1) PP-warning: Illegal Received field on preceding line Original-Received: by NeXT Mailer (1.87.1) PP-warning: Illegal Received field on preceding line To: HTX-HCI-MailingList@next2.lirmm.fr Subject: Call for papers IWHD'95 (to disseminate) Please help us widely disseminate the call for papers. Thanks. -------------------------------------------- --- CALL FOR PAPERS --- IWHD'95 I N T E R N A T I O N A L W O R K S H O P ON H Y P E R M E D I A D E S I G N June 1 - June 2 1995 Montpellier (France) Organized by : LIRMM / CNRS UM-II In cooperation with : (Cooperation requested from:) ACM SIGLINK, INRIA, CWI, ERCIM SCOPE IWHD'95 is the second in a series of International Workshops which aim at promoting activities related to Hypermedia Design. The first workshop was co-located with ACM ECHT'94, the European conference on Hypermedia Technology. IWHD'95 provides researchers as well as professional designers with an opportunity to meet, present position papers, discuss their methods, models, tools, experiences and ongoing projects on Hypermedia Design. Reducing the production cost of hypermedia applications, reducing design delays, improving the quality of hypermedia products, enforcing usability is an important challenge for Information Industry. Increasing the efficiency of design environments, evaluating the effectiveness of the design methods on which they are based and of the applications produced with them requires mastering and tuning-up design methods, as well as proposing new methods and tools. This is an important R&D activity that is becoming increasingly visible within hypermedia and WWW communities. The two-days workshop aims at studying problems, comparing approaches, mixing experiences, and cross-fertilizing knowledge on hypermedia design among researchers and practitioners. TOPICS You are invited to participate in IWHD'95 and to submit short (3000 words) or long (6000 words) papers. Topics appropriate for the workshop include but are not limited to: Hypermedia applications design - Design methods and models - Experiences in Designing - Designing Hypermedia Applications on the Internet - Experiences in teaching Hypermedia Design Hypermedia applications evaluation - Methods for Evaluation - Evaluating Hypermedia Applications on the Internet - How to Evaluate Commercial products - Hypermedia and the Electronic Publishing Market - Hypermedia Usability and Hypermedia Ergonomics Hypermedia Engineering - Specifying Hypermedia Applications - Design Standards and Portability - Authoring Environments and Frameworks for Design - Tools for designing Hypermedia on the Internet - Computer-Aided Design, Collaborative Design. Specific Design Application Areas - Hypermedia Cultural Applications - Technical Documentation Hypermedia - Educational Hypermedia, Teaching with Hypermedia - Hypermedia and Advertising - Distributed Hypermedia Application Design DEADLINES March 1st 1995 Submission: Full papers, in English, short (3000 words) or long (6000 words) should be received by the conference secretariat, both in paper and electronic form. Detailed specifications for submission are available by sending E-mail to iwhd95@lirmm.fr with IWHD95 Guidelines Request in the subject line. Or browse WWW at URL: http://www.lirmm.fr/~mnanard/iwhd95/workshop.html April 15 1995 Notification of acceptance. May 10th 1995 Final copy of papers received by the conference secretariat for publication in the proceedings. Proceedings will be proposed to Springer Verlag Workshop Series for publication. IWHD'95 CONFERENCE Secretariat Corine Zicler LIRMM, 161 rue Ada, 34392 Montpellier cedex 5, France E-mail: zicler@lirmm.fr Voice: (33) 6741 8503 Fax: (33) 6741 85 00 IWHD'95 CONFERENCE Co-CHAIRS Marc Nanard, Jocelyne Nanard LIRMM, CNRS & UniversitI de Montpellier II, France Voice: (33) 67 41 85 17 Fax: (33) 67 41 85 85 E-mail: mnanard@lirmm.fr PROGRAM COMMITTEE CHAIR Franca Garzotto Dipartimento di Elettronica, Politecnico di Milano, Italy Voice: (39) 2-23993520 Fax: (39) 2-23993411 E-mail: garzotto@ipmel1.polimi.it US COORDINATION Tomas Isakowitz Information Systems Department, Stern School of Business New York University, NY 10012, USA Voice: (1) 212-998-0833 Fax: (1) 212-995-4228 E-mail: tisakowi@stern.nyu.edu PROGRAM COMMITTEE Bob Allen Bellcore (USA) Hugh Dubberly Apple (USA) Bob glushko Passage Systems (USA) Wendy Hall Southampton Univ. (United Kingdom) Lynda Hardman CWI (The Netherlands) Blake Ives S. M. Univ. Dallas, Tx (USA) Paul D. Kahn Dynamic Diagrams (USA) Cathy Marshall Texas A&M University (USA) Ryuichi Ogawa NEC (Japan) Kasper Osterbye Aalborg Univ.(Denmark) Paolo Paolini Politecnico di Milano(Italy) Vincent Quint INRIA(France) Antoine Rizk Euroclid (France) Wolfgang Schuler GMD (Germany) Daniel Schwabe PUC (Brazil) Jack Shiff Siemens (Germany) Manfred Thuring Empirica CTR (Germany) Christine Vanoirbeek EPFL(Switzerland) ------------------- end of the cfp ------------- ---- HOW to SUBMIT (First Draft of the document sent upon request) How to submit : The workshop will consider two kinds of papers : long papers,) (about 5000 words), and shorter papers (about 3000 words). English is the official language. Any topic concerning methodologies or environments for designing or evaluating hypermedia applications, or experience in these domains are welcome for the workshop. All submissions to IWHD must be received by the secretariat before March 1st, both in electronic form and in paper form. A separate cover page with - the title of the paper, - the author list, - the affiliation, - the address including full postal address, phone number (voice and Fax) E-Mail address, if any. - an abstract (200 words), - a list of relevant keyword, should be added to the submission. Five copies of the submitted paper should be sent to : IWHD'95 CONFERENCE Secretariat Corine Zicler LIRMM, 161 rue Ada, 34392 Montpellier cedex 5, France E-mail: zicler@lirmm.fr Voice: (33) 6741 8503 Fax: (33) 6741 85 00 An electronic version of the paper ***which is strictly mandatory too*** must also be received by the secretariat at the same date. it must contain: - the ascii text of the cover page, sent directly as textual content of an E-Mail sent to : iwhd95@lirmm.fr with the subject line : IWHD95-abstract. - the formatted submitted document itself. The best way is to send the it as an Eudora attachment to an E-Mail sent to : iwhd95@lirmm.fr with the subject line : IWHD95-submission. If you have problems with your mail server when sending large files, you may use FTP as an alternate solution. A drop-in directory named 'iwhd95.drop-in' is available in the ftp server of LIRMM. - The hostname is: ftp.lirmm.fr - Its internet address is: 193.49.104.10 - The local pathname of the directory is: incoming/iwhd95.drop-in - The local pathname of the directory might be subject to changes due to reorganizing the ftp directory. So, if needed, explore! You must uuencode or binhex your file and put it in the drop-in directory, Use binary mode for transfer. The electronic version may be in either of the 4 following forms : - Microsoft Word for Mac or for PC - RTF - Latex - Postscript. Microsoft Word for Mac is the preferred one. Presentation rules: The proceedings will be produced from camera ready copies. In order to have a consistent presentation, very precise guidelines will be provided for producing the final version. Nevertheless, the Program Committee will appreciate that submissions be already presented according to the guidelines. A file named IWHD.MSWord.Template.hqx is located in the ftp directory iwhd95. you may get it by ftp anonymous. Then convert it with the binhex4 converter to obtain a MSWord file that you can use an a model for presenting your paper. Remark : the file IWHD.MSWord.Template.hqx will be available on the ftp site only after January 15 1995 Explicit data about the formatting will be placed on the web as soon as possible on the URL: http://www.lirmm.fr/lirmm/manifs/manifs.html Marc and Jocelyne Nanard Franca Garzotto. Tomas Isakowitz From rem-conf-request@es.net Thu Dec 08 08:03:40 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <03274-0@osi-west2.es.net>; Thu, 8 Dec 1994 07:14:33 -0800 Received: from msf.psi.net by osi-west.es.net via ESnet SMTP service id <14204-0@osi-west.es.net>; Thu, 8 Dec 1994 07:13:51 +0000 Received: from msf.psi.net (localhost) by msf.psi.net. (5.0/SMI-SVR4) id AA07339; Thu, 8 Dec 1994 10:10:37 +0500 Message-Id: <9412081510.AA07339@msf.psi.net.> To: Van Jacobson Cc: ietf@ietf.cnri.reston.va.us, rem-conf@es.net Subject: Re: vic use during ietf video feed In-Reply-To: Your message of "Wed, 07 Dec 1994 10:50:50 PST." <9412071850.AA18342@rx7.ee.lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <7337.786899436.1@msf.psi.net> Date: Thu, 08 Dec 1994 10:10:37 -0500 From: "Mark S. Fedor" content-length: 2630 I wouldn't mind having certain sessions broadcast with vic. I think the lack of platform support in vic right now takes lots of people out of the game. I for one just switched to solaris 2.3 (you can send me sympathy cards.... :^) and vic doesn't work well on this. All indications >from the readme's state that solaris 2.3 is a dead issue with vic. I think that vic should be tested, but in parallel or just certain predefined sessions. This would be in the proper spirit of "sharing of resources" that has taken place on the mbone to date. mf > I'd like to get an opinion from people watching the ietf video > feed on the mbone. Steve McCanne put a tremendous effort into > getting the vic release out a week before ietf so that we might > have a chance of using it for some of the meeting. (Old timers > might remember that the first, binary-only, release of nv > happened <24 hours before the Dec.'92 ietf where it was first > used so we thought a source+binary release a week before the > meeting, while not optimal, would be acceptable.) There were > two reasons for doing this: > > - vic is the first complete (so far as we know) implementation > of rtpv2 so it gives us a chance to try out the monitoring & > diagnostic capabilities of rtpv2 in a large-scale conference. > > - vic gives a *much* higher framerate than nv for the same > bandwidth, quality & loss tolerance. (In the one try we got to > do during the IDMR session, nv was giving .2-.3 frames/sec @ > 100kb/s. We switched to vic/h261 and got 8-10 frames/sec at > the same bandwidth, a factor of 30 improvement. Qualitatively, the > difference was between a slow slide show & real, full-motion video. > > Carl Malamud & the Internet Multicasting Service who are doing > the feed (& doing a great job) have said they'd be glad to do > whatever the viewer community wants. Steve Casner has been very > reluctant to allow the test. I don't understand most of the > reasons given for this but the one technical objection seemed to > be the lack of a 'recording' facility for rtpv2 sessions. So, > I've put the source of an rtpv2 recording app in > ftp://ftp.ee.lbl.gov/conferencing/vic/rtp_record.cc > The rules to build this are already in the vic makefile so you > should be able to just stick this source in your vic directory & > type "make rtp_record". > > So this is a question for the audience: Would you mind if we > used vic rtpv2 format for some of the ietf sessions? I.e., would > a 30-times improvement in framerate & much better diagnostic > capability bother you? (And if so, why?) Thanks. > > - Van From rem-conf-request@es.net Thu Dec 08 08:19:36 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <03330-0@osi-west2.es.net>; Thu, 8 Dec 1994 08:01:10 -0800 Received: from cs.nps.navy.mil by osi-west.es.net via ESnet SMTP service id <14582-0@osi-west.es.net>; Thu, 8 Dec 1994 08:00:32 +0000 Received: from bond.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA17056; Thu, 8 Dec 94 08:00:51 PST Date: Thu, 8 Dec 1994 08:00:50 +48000 From: Michael Macedonia To: mbone@ISI.EDU Cc: Pavel Curtis , rem-conf@es.net Subject: MUDs and mcast In-Reply-To: <93Jun7.151921pdt.58372@mu.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Does anyone know of anyone working on using IP multicast and/or mbone for MUDs/MOOs/MUSHs? I am meeting with a MUD research group that is interested in the idea and I would like to point out examples and prevent reinventing the wheel. Thanks, Mike Macedonia | macedonia@cs.nps.navy.mil MAJ, USA | CS Dept, Naval Postgraduate School, | Monterey, CA 93943 | PH:(408) 656-2903 FAX:(408) 656-2814 ------------------------------------------------------------ From rem-conf-request@es.net Thu Dec 08 08:57:04 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <03453-0@osi-west2.es.net>; Thu, 8 Dec 1994 08:44:16 -0800 Received: from ocfmail.ocf.llnl.gov by osi-west.es.net via ESnet SMTP service id <14949-0@osi-west.es.net>; Thu, 8 Dec 1994 08:41:36 +0000 Received: by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA25176; Thu, 8 Dec 94 08:41:34 PST Date: Thu, 8 Dec 94 08:41:34 PST From: wiltzius@ocfmail.ocf.llnl.gov (David P Wiltzius) Message-Id: <9412081641.AA25176@ocfmail.ocf.llnl.gov> To: rem-conf@es.net Subject: multi-homed mcast xmiters I've been told that this is a reasonable mailing list for the following question: I have a machine that has two multicast capable (IFF_MULTICAST) interfaces - an SGI Indy. I would like to multicast an MBONE session, but only over one Ethernet. Can I temporarily disable multicast transmissions to one interface? Mrouted is not being run on this machine since I want to keep both networks separate (in fact, one interface is Ethernet and the other is OC-3 ATM; I want to transmit at high throughput on the ATM, but this must not go over the Ethernet). I could run mrouted if it could help. *Please* respond or cc my email as I just now mailed my request to join this list. Thanks. Dave Wiltzius LLNL wiltzius@llnl.gov From rem-conf-request@es.net Thu Dec 08 11:16:27 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <04006-0@osi-west2.es.net>; Thu, 8 Dec 1994 11:01:58 -0800 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <16040-2@osi-west.es.net>; Thu, 8 Dec 1994 11:01:09 +0000 Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <14882(8)>; Thu, 8 Dec 1994 10:41:53 PST Received: from localhost by mu.parc.xerox.com with SMTP id <58381>; Thu, 8 Dec 1994 10:39:16 -0800 To: Michael Macedonia Cc: mbone@isi.edu, rem-conf@es.net Subject: Re: MUDs and mcast In-reply-to: Michael Macedonia's message of "Fri, 18 Nov 94 00:00:50 PST" Date: Thu, 8 Dec 1994 10:32:51 PST Sender: Pavel Curtis From: Pavel Curtis Message-Id: <94Dec8.103916pst.58381@mu.parc.xerox.com> Michael Macedonia writes: > Does anyone know of anyone working on using IP multicast and/or mbone for > MUDs/MOOs/MUSHs? I am meeting with a MUD research group that is > interested in the idea and I would like to point out examples and prevent > reinventing the wheel. The Jupiter system here at PARC makes routine use of IP multicast for live video and for live and recorded audio; we also anticipate using it for `telepointer' data (other users' mouse motions). Here's my standard squib about Jupiter: You can read the only existing public paper about Jupiter at this URL: ftp://ftp.parc.xerox.com/pub/MOO/papers/MUDsGrowUp.ps Jupiter is a set of enhancements that can be added to any LambdaMOO system. The release, expected in early 1995, will include the following: -- a great deal of MOO code implementing simple programming interfaces to the whole range of new Jupiter functionality, -- detailed documentation of those interfaces, -- detailed specifications of the protocols used for server/client communication in support of the new functionality, and -- sources and executables for client programs running on several UNIX platforms and on MS Windows 3.1. Jupiter runs on an unmodified LambdaMOO server. A Macintosh client was originally planned for inclusion in this release, but has been sufficiently delayed that inclusion is no longer possible without unacceptably slipping the release schedule. The main components of Jupiter are as follows: -- a general-purpose window system, allowing MOO objects to display standard graphical user interfaces on the client's screen, without needing to know what kind of window system is native for the client, and with persistence and sharing of all window widget state provided automatically by default, -- live audio transmission between all users in the same virtual location, -- live video images of all users in the same virtual location, and -- simple facilities for sharing external files and some external applications between users, even when they do not share a file system. The use of audio and video requires IP multicast connectivity between all participants. The Jupiter release will be made by anonymous FTP, free for non-commercial use. Potential commercial users should wait until the release is announced and then contact us for possible licensing terms. Pavel From rem-conf-request@es.net Thu Dec 08 20:55:21 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <00799-0@osi-west2.es.net>; Thu, 8 Dec 1994 20:50:27 -0800 Received: from inet-gw-2.pa.dec.com by osi-west.es.net via ESnet SMTP service id <20538-0@osi-west.es.net>; Thu, 8 Dec 1994 20:50:16 +0000 Received: from bigpink.pa.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AB14564; Thu, 8 Dec 94 20:47:27 -0800 Received: by bigpink.pa.dec.com; id AA05784; Thu, 8 Dec 1994 20:47:20 -0800 Message-Id: <9412090447.AA05784@bigpink.pa.dec.com> To: rem-conf@es.net Subject: feedback - h.261 mcast during IETF Date: Thu, 08 Dec 94 20:47:20 -0800 From: berc@pa.dec.com X-Mts: smtp I ran a pair of vics side by side during the last couple of sessions of the IETF mcast, and asked passers-by what they thought of the difference between the h.261 and nv windows. The man-in-the-hallway results are (a) the h.261 was better than nv for people, (b) nv was better for slides (no DCT ringing), and (c) this MBone stuff was much better than they had thought. Comments? lance From rem-conf-request@es.net Fri Dec 09 01:01:45 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <01742-0@osi-west2.es.net>; Fri, 9 Dec 1994 00:40:25 -0800 Received: from everest.cclabs.missouri.edu by osi-west.es.net via ESnet SMTP service id <21999-0@osi-west.es.net>; Fri, 9 Dec 1994 00:36:58 +0000 Received: from sgi2.phlab.missouri.edu (sgi2.phlab.missouri.edu [128.206.115.32]) by everest.cclabs.missouri.edu (8.6.9/8.6.6-Arete) with SMTP id CAA17027; Fri, 9 Dec 1994 02:36:35 -0600 Date: Fri, 9 Dec 1994 02:36:34 -0600 (CST) From: Paul 'Shag' Walmsley X-Sender: ccshag@sgi2.phlab.missouri.edu To: "Mark S. Fedor" cc: Van Jacobson , ietf@ietf.cnri.reston.va.us, rem-conf@es.net Subject: Re: vic use during ietf video feed In-Reply-To: <9412081510.AA07339@msf.psi.net.> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Personally, I am in favor of broadcasting IETF vic sessions in parallel. I think that this is a reasonable compromise between those who can't upgrade to nv and those who wish to test vic. It also would allow for some nifty side-by-side comparisons of vic and nv performance. - Paul "Shag" Walmsley "The only difference between myself and a madman is that I am not mad." - Salvador Dali From rem-conf-request@es.net Fri Dec 09 01:41:46 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <01774-0@osi-west2.es.net>; Fri, 9 Dec 1994 00:52:25 -0800 Received: from ceres.fokus.gmd.de by osi-west.es.net via ESnet SMTP service id <22280-0@osi-west.es.net>; Fri, 9 Dec 1994 00:52:14 +0000 Received: from ursa.fokus.gmd.de by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Fri, 9 Dec 1994 09:50:16 +0100 X-Mailer: exmh version 1.5.1 12/2/94 To: rem-conf@es.net From: Henning Schulzrinne Subject: Re: vic use during ietf video feed Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 09 Dec 94 09:50:40 +0100 Sender: schulzrinne@fokus.gmd.de It should be noted that, according to our local systems folk, Solaris 2.4 won't be available in Germany before February 1995. Henning From rem-conf-request@es.net Fri Dec 09 03:58:59 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <02375-0@osi-west2.es.net>; Fri, 9 Dec 1994 03:51:55 -0800 Received: from mailgzrz.TU-Berlin.DE by osi-west.es.net via ESnet SMTP service id <24088-0@osi-west.es.net>; Fri, 9 Dec 1994 03:51:41 +0000 Received: from w250zrz.zrz.TU-Berlin.DE by mailgzrz.TU-Berlin.DE with SMTP (PP); Fri, 9 Dec 1994 12:51:34 +0100 Date: Fri, 9 Dec 94 12:51:31 +0100 From: John Mccall Richey Subject: Message-Id: <9412091151.AA10497@w250zrz.zrz.TU-Berlin.DE> To: rem-conf@es.net unsubscribe From rem-conf-request@es.net Fri Dec 09 05:30:41 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <02700-0@osi-west2.es.net>; Fri, 9 Dec 1994 05:25:10 -0800 Received: from mailer.psc.edu by osi-west.es.net via ESnet SMTP service id <24801-0@osi-west.es.net>; Fri, 9 Dec 1994 05:25:03 +0000 Received: from sabre.psc.edu by mailer.psc.edu (5.65/Ultrix3.0-C 11/12/92 nydick) id AA00475; Fri, 9 Dec 1994 08:24:31 -0500 Message-Id: <9412091324.AA00475@mailer.psc.edu> To: berc@pa.dec.com Cc: rem-conf@es.net, mahdavi@sabre.psc.edu Subject: Re: feedback - h.261 mcast during IETF In-Reply-To: Your message of "Thu, 08 Dec 1994 20:47:20 PST." <9412090447.AA05784@bigpink.pa.dec.com> Date: Fri, 09 Dec 1994 08:24:25 -0500 From: Jamshid Mahdavi > > I ran a pair of vics side by side during the last couple of sessions > of the IETF mcast, and asked passers-by what they thought of the > difference between the h.261 and nv windows. The man-in-the-hallway > results are (a) the h.261 was better than nv for people, (b) nv was > better for slides (no DCT ringing), and (c) this MBone stuff was > much better than they had thought. I didn't get a chance to watch any of the vic broadcast, but for the first time last night I was able to watch a working group broadcast and really feel like I was there (this was the TCPng BOF). The folks doing the production at this IETF did an excellent job! --Jamshid From rem-conf-request@es.net Fri Dec 09 07:43:32 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <02908-0@osi-west2.es.net>; Fri, 9 Dec 1994 07:37:59 -0800 Received: from her001.phy.ornl.gov by osi-west.es.net via ESnet SMTP service id <25522-0@osi-west.es.net>; Fri, 9 Dec 1994 07:37:31 +0000 Received: (from saini@localhost) by her001.phy.ornl.gov (8.6.8.1/8.6.8) id KAA01899; Fri, 9 Dec 1994 10:37:19 -0500 Date: Fri, 9 Dec 1994 10:37:19 -0500 From: surender saini Message-Id: <199412091537.KAA01899@her001.phy.ornl.gov> To: mbone@isi.edu Subject: IP multicast software Cc: rem-conf-request@es.net, rem-conf@es.net Does anyone has /or know of anyone working on IP multicast Kernel patch and mrouted for OS9. I will appreciate this information very much. We would like to multicast real-time data from a CPU board sitting in a VME crate and running OS9 operating system. Unfortunately, the OS9 kernel does not have IP multicast capability. Thanks, Surender Saini | Email: SAINI@orph01.phy.ornl.gov | ORNL, USA | Physics Division, Bldg. 6003, MS. 372 | | Oak Ridge National Laboratory, Oak Ridge, TN. 37831,USA| | Tel:(615)574-8349, FAX:(615)576-2822, VOX:(615)470-1013| +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From rem-conf-request@es.net Fri Dec 09 09:06:52 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <03052-0@osi-west2.es.net>; Fri, 9 Dec 1994 09:01:09 -0800 Received: from driene.student.utwente.nl by osi-west.es.net via ESnet SMTP service id <26533-0@osi-west.es.net>; Fri, 9 Dec 1994 09:00:57 +0000 Received: from [130.89.41.55] (utto1055.to.utwente.nl) by student.utwente.nl with SMTP id AA14090 (5.67b/IDA-1.5 for ); Fri, 9 Dec 1994 18:00:49 +0100 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 9 Dec 1994 18:00:52 +0100 To: rem-conf@es.net From: m.p.vanegeraat@student.utwente.nl (Maurice van Egeraat) unsubscribe +------------------------------------------------------------+ | Maurice van Egeraat | | Witbreuksweg 379-307, 7522 ZA Enschede | | The Netherlands | | Tel. (+31)53895130 or (+31)546820629 | | E-Mail : M.P.VANEGERAAT@STUDENT.UTWENTE.NL | | URL: http://utto237.utwente.nl/TO/OnLIne/Maurice/MvE.html | +------------------------------------------------------------+ From rem-conf-request@es.net Fri Dec 09 12:07:39 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <03765-0@osi-west2.es.net>; Fri, 9 Dec 1994 12:01:53 -0800 Received: from wizard.gsfc.nasa.gov by osi-west.es.net via ESnet SMTP service id <28206-0@osi-west.es.net>; Fri, 9 Dec 1994 12:01:45 +0000 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA14636; Fri, 9 Dec 94 15:01:41 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9412092001.AA14636@wizard.gsfc.nasa.gov> Subject: Re: feedback - h.261 mcast during IETF To: rem-conf@es.net Date: Fri, 9 Dec 1994 15:01:41 -0500 (EST) In-Reply-To: <9412090447.AA05784@bigpink.pa.dec.com> from "berc@pa.dec.com" at Dec 8, 94 08:47:20 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1126 > I ran a pair of vics side by side during the last couple of sessions > of the IETF mcast, and asked passers-by what they thought of the > difference between the h.261 and nv windows. The man-in-the-hallway > results are (a) the h.261 was better than nv for people, (b) nv was > better for slides (no DCT ringing), and (c) this MBone stuff was > much better than they had thought. > > Comments? > > lance I also did side by side comparisons of nv and vic with the same general impression, that vic was better for motion such as people and nv was more stable for slides. Some of the later vic transmissions seemed to be better on showing slides. I noticed a button in vic for 'Sending Slides' but I don't know if this was used or if the camera was just steadier. I also agree with another comment that the best way of showing slides is via wb. In fact, during one of the sessions that was using wb to display the sides, I heard comments from the room that the overhead projector was continually going out of focus and I had to chuckle to myself since the wb display was remaining crystal clear. :-) -Bill From rem-conf-request@es.net Fri Dec 09 13:02:06 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <03941-0@osi-west2.es.net>; Fri, 9 Dec 1994 12:55:58 -0800 Received: from ell.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <28759-0@osi-west.es.net>; Fri, 9 Dec 1994 12:55:36 +0000 Received: by ell.ee.lbl.gov (8.6.9/1.43r) id MAA21167; Fri, 9 Dec 1994 12:19:23 -0800 From: mccanne@ee.lbl.gov (Steven McCanne) Message-Id: <199412092019.MAA21167@ell.ee.lbl.gov> To: berc@pa.dec.com cc: rem-conf@es.net Subject: Re: feedback - h.261 mcast during IETF In-reply-to: Your message of Thu, 08 Dec 94 20:47:20 -0800. <9412090447.AA05784@bigpink.pa.dec.com> Date: Fri, 09 Dec 94 12:19:23 PST > (a) the h.261 was better than nv for people, (b) nv was > better for slides (no DCT ringing) This agrees with my observations while developing our H.261 coder. Wavelet transforms in general are good at isolating local artifacts (like edges in text), while the DCT tends to introduce ringing as Lance points out. The reason is that wavelet basis functions are localized in time, while sinusoidal basis functions are infinite in time. When applied to finite 8x8 blocks, this means that an error in a DCT coefficient (i.e., due to lossy coding) is spread out across the entire block. This reaffirms that there is probably not a universal, "best" coding scheme. The fact that machines are getting fast enough to do everything is software allows us to select the best coding format at the click of a button. I think it is a mistake to expect there to be only a single button (labeled "MPEG"). Steve From rem-conf-request@es.net Fri Dec 09 15:12:29 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <00416-0@osi-west2.es.net>; Fri, 9 Dec 1994 14:59:32 -0800 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <00327-0@osi-west.es.net>; Fri, 9 Dec 1994 14:59:21 +0000 Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 9 Dec 1994 22:58:22 +0000 To: bill@wizard.gsfc.nasa.gov (Bill Fink) cc: rem-conf@es.net Subject: Re: feedback - h.261 mcast during IETF In-reply-to: Your message of "Fri, 09 Dec 94 15:01:41 EST." <9412092001.AA14636@wizard.gsfc.nasa.gov> Date: Fri, 09 Dec 94 22:58:12 +0000 From: Gordon Joly Slides are better done via HTTP than nv or vic or wb. Piete Brooks seems to have thought of that. Gordo Gordon Joly Email: G.Joly@cs.ucl.ac.uk +441713807934 FAX +441713871397 Computer Science, University College London, Gower St., LONDON WC1E 6BT http://www.cs.ucl.ac.uk/people/gordo/ http://artaids.dcs.qmw.ac.uk:8001/ From rem-conf-request@es.net Fri Dec 09 15:58:33 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <00386-0@osi-west2.es.net>; Fri, 9 Dec 1994 15:50:02 -0800 Received: from ell.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <00833-0@osi-west.es.net>; Fri, 9 Dec 1994 15:49:50 +0000 Received: by ell.ee.lbl.gov (8.6.9/1.43r) id PAA21761; Fri, 9 Dec 1994 15:49:45 -0800 From: mccanne@ee.lbl.gov (Steven McCanne) Message-Id: <199412092349.PAA21761@ell.ee.lbl.gov> To: Khoi Nguyen cc: af@crl.dec.com, rem-conf@es.net Subject: Re: Developments on DECaudio's DSP56k ... In-reply-to: Your message of Fri, 09 Dec 94 13:36:24 -0600. Date: Fri, 09 Dec 94 15:49:45 PST [I've cc'd rem-conf because there was a related thread a month ago on acoustic echo cancellation for audio conferencing.] > I am planning to do echo cancellation on the DECaudio's DSP56k. A while back, I did a term project where I added DECaudio/56001 support to UCB's Ptolemy DSP design environment. I then used this framework to do an acoustic echo canceller for audio conferencing. The results weren't exactly stellar. The problem is that you need about 1000 taps to good acoustic cancellation with an LMS FIR filter. The 56001 in the DECaudio can hack only about 200 taps. For anyone interested, I've put a copy of my project writeup in ftp://ftp.ee.lbl.gov/papers/sm-echo93.ps.Z (Disclaimer: this was a term project subject to the usual time pressures etc. I haven't had time in the interim to work on this stuff.) My feeling (shared by others) is that as machines get fast enough, we'll do echo cancellation in software. But at 8Khz and 1000 taps, you only get 125 us / 1000 = 125 ns per tap. That's an infeasibly small CPU budget. There are techniques based on adaptive IIR filters and on subband decomposition that give better performance at lower computational complexity. We (in the networking/conferencing world) need to take a closer look at this work. The problem pointed out in the rem-conf thread was that operating systems typically don't provide a way to precisely correlate the input and output signals from an audio device. The reason for this is that O/S developers tend not to think about things like adaptive signal processing. We've tried to fix this problem in the 4.4BSD audio driver, which Chris Torek and I did for the sparc. I believe the same driver architecture has been adopted by the 4.4 Lite derivatives. You actually can achieve synchronization in Sun's STREAMS audio interface by (1) pausing the device, (2) flushing the queues, (3) writing a block of samples, then (4) resuming the device. Future reads are then exactly correlated with writes (as long as there are never underruns -- which you can check against and re-sync as they happen). I have tried this and it does work. Steve From rem-conf-request@es.net Fri Dec 09 20:15:26 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <00839-0@osi-west2.es.net>; Fri, 9 Dec 1994 20:10:28 -0800 Received: from jaring.my by osi-west.es.net via ESnet SMTP service id <02657-0@osi-west.es.net>; Fri, 9 Dec 1994 20:10:15 +0000 Received: from srb.UUCP by jaring.my with UUCP id AA03337 (5.67a/IDA-1.5 for rem-conf@es.net); Sat, 10 Dec 1994 12:10:10 +0800 Message-Id: <199412100410.AA03337@jaring.my> Received: from srb by srb.pl.my (UUPC/extended 1.12b) with UUCP; Sat, 10 Dec 1994 06:00:26 GMT From: Saravana Ram Balakrishnan To: rem-conf@es.net Date: Sat, 10 Dec 1994 06:00:25 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Reply-To: Saravana Ram Priority: normal X-Mailer: PMail v3.0 (R1a) unsubscribe -- Saravana Ram Balakrishnan Tel: +60-3-255-9841 ram%srb%pl.my@csah.sg.com From rem-conf-request@es.net Fri Dec 09 21:20:32 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <01064-0@osi-west2.es.net>; Fri, 9 Dec 1994 21:14:16 -0800 Received: from koriel.Sun.COM by osi-west.es.net via ESnet SMTP service id <03138-0@osi-west.es.net>; Fri, 9 Dec 1994 21:14:07 +0000 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA14556; Fri, 9 Dec 94 21:13:54 PST Received: from auckland.Eng.Sun.COM by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA09450; Fri, 9 Dec 94 21:14:49 PST Received: by auckland.Eng.Sun.COM (5.x/SMI-SVR4) id AA00865; Fri, 9 Dec 1994 21:13:46 -0800 Date: Fri, 9 Dec 1994 21:13:46 -0800 From: Ross.Finlayson@Eng.Sun.COM (Ross Finlayson) Message-Id: <9412100513.AA00865@auckland.Eng.Sun.COM> To: bill@wizard.gsfc.nasa.gov, G.Joly@cs.ucl.ac.uk Subject: Re: feedback - h.261 mcast during IETF Cc: rem-conf@es.net Reply-To: finlayson@Eng.Sun.COM X-Sun-Charset: US-ASCII > Slides are better done via HTTP than nv or vic or wb. Surely you can't be serious. HTTP is a point-to-point protocol, with all of the corresponding scaling problems if the number of viewers becomes large. Now, one might argue that slides should be *formatted* in HTML (!= HTTP), so that they could be viewed by WWW browsers - this is what the French "MCM" sessions do, I believe. (However, HTML makes it difficult to add annotations to the slides in real time.) But in order for the *distribution* of slides to scale well to large numbers of viewers, you need some sort of hierarchical distribution mechanism - e.g., multicast groups. BTW, this reminds me - Is there any publically-available document out there that describes the reliability mechanisms used by the "wb" protocol? A few people have mentioned a related presentation that Van Jacobson made in a tutorial at the last SIGCOMM (which I didn't attend). Van, were the slides for this made available? Ross. From rem-conf-request@es.net Sat Dec 10 00:09:14 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <01754-0@osi-west2.es.net>; Sat, 10 Dec 1994 00:03:13 -0800 Received: from rx7.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <04468-0@osi-west.es.net>; Sat, 10 Dec 1994 00:02:57 +0000 Received: by rx7.ee.lbl.gov for rem-conf@es.net (5.65/1.44r) id AA22050; Sat, 10 Dec 94 00:05:59 -0800 Message-Id: <9412100805.AA22050@rx7.ee.lbl.gov> To: bill@wizard.gsfc.nasa.gov (Bill Fink) Cc: berc@pa.dec.com, rem-conf@es.net Subject: Re: feedback - h.261 mcast during IETF In-Reply-To: Your message of Fri, 09 Dec 94 15:01:41 EST. Date: Sat, 10 Dec 94 00:05:58 PST From: Van Jacobson > I also did side by side comparisons of nv and vic with the same > general impression, that vic was better for motion such as > people and nv was more stable for slides. Some of the later vic > transmissions seemed to be better on showing slides. I noticed > a button in vic for 'Sending Slides' but I don't know if this > was used or if the camera was just steadier. No, the change was probably that during the IDMR & MMUSIC sessions I had the quantizer set pretty coarse (14) which gave a high frame rate but lots of ringing & DCT basis vector artifacts on the slides (but they were also being sent out via wb so I thought this would be ok). During the plenary sessions the quantizer was set to the default (10) which does ok on slides (I find the artifacts aren't visible unless I switch to the biggest window size but my eyes aren't that great so your milage may vary) but at a significantly lower frame rate (2-4 f/s instead of the 8-10 we saw during idmr) -- part of this change was due to the quantizer & part to the fact that the plenary had much more panning, zooming & crowd motion than the idmr session. Even at the finer quantizer setting, the frame rate was 4-5 times that of the parallel nv feed (Steve McCanne says this is what theory would predict for full frame updates -- there's a factor of two gain from the "energy compaction" of the DCT & another factor of two from the entropy coding). The blockiness in the plenary video was mostly due to the scene being way too dark (Carl told me his cameras were giving lots of trouble & the auto-iris on at least one seems to have died). Since the vic h.261 encoder uses a fixed quantizer, this meant that the little bit of the luminance dynamic range that was being used covered just a few quantization levels which translates into easily visible block artifacts. At some point we hope to add either an adaptive quantizer to vic (but this is computationally expensive) and/or a transmit "setup" button that will expand to luminance signal from the camera/capture board to cover the entire CCIR-601 dynamic range. In the meantime it's a good idea to adjust the camera so that the scene coming out of the capture board looks & stays fairly bright. - Van From rem-conf-request@es.net Sat Dec 10 02:04:32 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <02136-0@osi-west2.es.net>; Sat, 10 Dec 1994 01:57:46 -0800 Received: from rx7.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <05411-0@osi-west.es.net>; Sat, 10 Dec 1994 01:57:35 +0000 Received: by rx7.ee.lbl.gov for rem-conf@es.net (5.65/1.44r) id AA22135; Sat, 10 Dec 94 02:00:39 -0800 Message-Id: <9412101000.AA22135@rx7.ee.lbl.gov> To: finlayson@eng.sun.com Cc: G.Joly@cs.ucl.ac.uk, rem-conf@es.net Subject: Re: feedback - h.261 mcast during IETF In-Reply-To: Your message of Fri, 09 Dec 94 21:13:46 PST. Date: Sat, 10 Dec 94 02:00:39 PST From: Van Jacobson Ross, Sigcomm plans to do something with my tutorial notes (I'm not sure what) & have asked me not to distribute them. But I did give a talk at Sun on wb & its protocol in Apr 93 that covered most everything that was in the tutorial. I think it was videotaped & Allyn or Don Hopkins might know if the tape or viewgraphs are still around. The original protocol design that Steve McCanne & I did has held up pretty well (although the implementation in wb is still incomplete & weak) so the Apr '93 notes are still valid. There are some recent changes in the repair machinery (at a level of detail not covered in the notes) suggested by Sally Floyd on the basis of simulations studies done about a year ago. There's been ongoing work here & at Xerox PARC (under Lixia Zhang) looking at the scaling of the protocol (which appears to be very good) and at developing "local repair" machinery to deal more efficiently with large variations of link quality in very large scale conferences (this issue only arises when there are a lot of members spread over a very large geographic area & a few of the leaf links are very flakey). Lixia & Sally have suggested that they, Steve & I do a paper on this work for the next Sigcomm. I'm not sure when the submission deadline is but if it's far enough in the future this will probably happen. - Van ps- Much of the wb protocol was taken directly from MIT's NETBLT (basically we added multicast & the notion of data/sender decoupling to NETBLT) so, if you haven't read them, the Clark/Zhang/et.al., papers on NETBLT contain a lot of key ideas & important background. From rem-conf-request@es.net Sat Dec 10 06:27:41 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <03013-0@osi-west2.es.net>; Sat, 10 Dec 1994 06:22:44 -0800 Received: from ceres.fokus.gmd.de by osi-west.es.net via ESnet SMTP service id <06761-0@osi-west.es.net>; Sat, 10 Dec 1994 06:11:31 +0000 Received: from ursa.fokus.gmd.de by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Sat, 10 Dec 1994 15:09:39 +0100 X-Mailer: exmh version 1.5.1 12/2/94 To: rem-conf@es.net From: Henning Schulzrinne Subject: And you thought a *multicast* radio station was bad... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 10 Dec 94 15:10:04 +0100 Sender: schulzrinne@fokus.gmd.de If this is a trend, we can forget about MBONE quality for the time being. (from comp.internet.net-happenings) > SENDER: WXYC Tech Admin > Subject: CU-SeeMe > WXYC, the U. of NC @ Chapel Hill's non-commercial/educational student > radio station, is simulcasting in real-time over Internet using CU-SeeMe > and Vat. We are rebroadcasting from UNC's SunSITE. > We would like listeners world-wide to connect and comment on signal ^^^^^^^^^^ > quality, etc. Interested folks should connect to 152.2.22.81. Expect > high-speed lines to work best, for obvious reasons. > The latest ver of CU-SeeMe (for Mac SE/30 or better, Sys 7 or higher) is > available from gated.cornell.edu via anon FTP, in the /pub/video directory. > Get the CU-SeeMe README file too. > I have a complete "press release" if that would be of interest. > Also, WXYC WWW page: URL = http://sunsite.unc.edu/wxyc/ has more info. Henning From rem-conf-request@es.net Sat Dec 10 20:12:56 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <04260-0@osi-west2.es.net>; Sat, 10 Dec 1994 20:08:18 -0800 Received: from cs.uml.edu by osi-west.es.net via ESnet SMTP service id <10889-0@osi-west.es.net>; Sat, 10 Dec 1994 20:08:07 +0000 Received: by cs.uml.edu id AA20026 (5.67a+/IDA-1.5 for rem-conf@es.net); Sat, 10 Dec 1994 23:07:42 -0500 From: "John F. Buford" Message-Id: <199412110407.AA20026@cs.uml.edu> Subject: Public Review of ISO MHEG DIS text To: rem-conf@es.net Date: Sat, 10 Dec 1994 23:07:41 -0500 (EST) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1141 ANNOUNCING PUBLIC REVIEW OF PROPOSED ISO MHEG DIS TEXT The proposed draft international standard text for MHEG, officially ISO/IEC DIS 13522-1 (MHEG Part 1), is available for public review. MHEG (Multimedia and Hypermedia information encoding Expert Group) is an object-oriented encoding of multimedia and hypermedia information for final-form real-time delivery applications. Part 1 uses ASN.1 encoding. Part 2 will use SGML. The text is being balloted for DIS status by countries which are members of ISO JTC1/SC29. Comments on the text can be sent directly to your national body representative, or to the convener of SC29/WG12, Mme. Francoise Colaitis, Francoise.Colaitis@ccett.fr. In the US, comments on the text can be sent to buford@cs.uml.edu. Please send comments by Jan 12. The 400 page document can be obtained via anonymous ftp to node 129.63.26.14 in directory pub/MHEG. Via the web, use ftp://devo.uml.edu/pub/MHEG/DIS-[1-3].ps.gz or ftp://devo.uml.edu/pub/MHEG/DIS-[1-3].rtf.gz. -- Dr. John F. Buford Dept. of Computer Science, UMass--Lowell, Lowell, MA 01854 buford@cs.uml.edu (508) 934-3618 FAX: (508) 452-4298 From rem-conf-request@es.net Sun Dec 11 04:09:22 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <05762-0@osi-west2.es.net>; Sun, 11 Dec 1994 04:04:16 -0800 Received: from mailsun.aber.ac.uk by osi-west.es.net via ESnet SMTP service id <13727-0@osi-west.es.net>; Sun, 11 Dec 1994 04:04:05 +0000 Received: from mailhost.aber.ac.uk (actually saturn.dcs.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (PP); Sun, 11 Dec 1994 12:03:47 +0000 To: rem-conf@es.net cc: list-mbone-dev@aber.ac.uk Subject: Sun's ShowMe Software and the MBONE Date: Sun, 11 Dec 1994 12:03:43 +0000 Message-ID: <9003.787147423@mailhost.aber.ac.uk> From: D E PRICE Dear All, We here in Aberystwyth joined the mbone over the last few weeks. Our first attempt was aborted when (Thanks to Steve Casner) we discovered some Lantronix boxes running an old version of the software were behaving badly when they spotted multicast traffic. All now fixed I hope, If anyone spots more bad ICMPs please tell us. Anyway, now onto the real point of this email. As well as using the various PD-ish software items like vat, ivs, wb, sd etcetc we have also bought copies of Suns ShowMe product. We have used them on-site and some parts are quite good. The Video component can generate good quality (we have one SunVideo card only at the moment) but has the potential to generate massive amounts of traffic. Its easy to get it over 4 Mbit/sec ! Now to two questions: 1/. Have people experimented with the Sun ShowMe product over the mbone and if so what did you think? How did you set parameters to keep bandwidth consumption down but keep quality acceptable? 2/. I am quite worried about the effect on the mbone if lots of people start to run tools. e.g. all the students with nv say and transmitting X windows...... A group of students know we are experimenting and know that they will be allowed to join in a controlled way at various times, but I generally leave permissions off on the filestore areas to have some control. However, as the software is sitting on various open ftp servers all over the world, there is little I can do in reality to stop them running off and collecting their own copies and using them. So, how are other people approaching the problem of managing MBONE usage etc at their sites? Dave Price ----------------------------------------------------------------- | David Price, Computer Science | | | | Computer Science, University of Wales, Aberystwyth, | | Penglais Campus, Aberystwyth, Dyfed, SY23 3DB | | | | Janet: dap@uk.ac.aber Internet: dap@aber.ac.uk | | Phone: +44 970 622428 FAX: +44 970 622455 | ----------------------------------------------------------------- From rem-conf-request@es.net Sun Dec 11 06:59:09 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <06082-0@osi-west2.es.net>; Sun, 11 Dec 1994 06:54:26 -0800 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <14394-0@osi-west.es.net>; Sun, 11 Dec 1994 06:54:16 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 11 Dec 1994 14:53:50 +0000 To: Van Jacobson cc: finlayson@eng.sun.com, G.Joly@cs.ucl.ac.uk, rem-conf@es.net, J.Crowcroft@cs.ucl.ac.uk Subject: Re: feedback - h.261 mcast during IETF In-reply-to: Your message of "Sat, 10 Dec 94 02:00:39 PST." <9412101000.AA22135@rx7.ee.lbl.gov> Date: Sun, 11 Dec 94 14:53:47 +0000 Message-ID: <1924.787157627@cs.ucl.ac.uk> From: Jon Crowcroft >Sigcomm plans to do something with my tutorial notes (I'm not >sure what) & have asked me not to distribute them. But I >did give a talk at Sun on wb & its protocol in Apr 93 that >covered most everything that was in the tutorial. I think it >was videotaped & Allyn or Don Hopkins might know if the tape or >viewgraphs are still around. SIGCOMM are using your notes as a special bonus for people who join the SIG this year.... however, we will put them on our web server in HTML (pace gordon joly) with video of you giving the course here this summer the nano-second this is okayed by lyman chapin or anyne else at ACM.... jon From rem-conf-request@es.net Mon Dec 12 04:05:09 1994 Received: from osi-west.nersc.gov by osi-west2.es.net via ESnet SMTP service id <08701-0@osi-west2.es.net>; Mon, 12 Dec 1994 04:00:17 -0800 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <20975-0@osi-west.es.net>; Mon, 12 Dec 1994 03:59:49 +0000 Received: from muridae.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 12 Dec 1994 11:59:27 +0000 To: rem-conf@es.net CC: mice-nsc@cs.ucl.ac.uk Subject: MICE Seminar: Tuesday 13th December at 14:00 UTC. Date: Mon, 12 Dec 94 11:58:47 +0000 From: Gordon Joly There will be a MICE seminar at 14:00 UTC tomorrow (Tuesday 13 December). There is an entry in "sd", on the usual address of 224.5.17.12. We will use vat, wb, and ivs 3.3 for video (you may wish to receive this using vic). In general, information on the MICE seminars kept up to date in the URL http://www.cs.ucl.ac.uk/mice/seminars/ Regards, Gordon Joly *********************** Abstact. *********************** THE COOPERATIVE SHARING OF INFORMATION Tom Rodden Computing Department Lancaster University Lancaster LA1 4YR Email: tom@comp.lancs.ac.uk Phone: +44 524 593823 Fax: +44 524 593608 Shared information plays a central role in Computer Supported Cooperative Work systems. It is often the primary means used to develop a shared understanding across a number of users working together. The nature of this sharing and the forms of coopera-tion it facilitates vary greatly from application to application. For example, some systems allow a number of potentially distributed users to work together in real time while annotation based systems allow users to work in a time-independent manner. Information sharing is strongly dependant on the facilities provided by the supporting distributed infrastructure. However, a mismatch often exists between the manner in which facilities are provided and the diverse nature of cooperative applications. This is most visible in the balance of control between users, applications and the management of the facilities provided by the supporting platform. Distributed systems have traditionally employed a prescriptive approach to management and control. Successful control has focused on hiding the problems associated with distributed systems >from users. Unfortunately, the combination of prescriptive control based on notions of transparency and the desire to create a single user view of the system can hide the existence of users from each other, actively prohibiting cooperation. In contrast to the existing system view of control, CSCW systems and environments need a user oriented view of control. This control needs to promote direct involvement of users in managing the cooperative aspects of the infrastructure. This talk examines the importance of providing effective management of sharing in cooperative systems and argues for a specialised service to support the cooperative aspects of information sharing. The relationship between the developed cooperative shared object service and existing distributed services is briefly examined. A number of management services of particular importance to CSCW systems are outlined. I will present a technique for realising a shared object service by augmenting existing object facilities to provide facilities to manage their cooperative use. These facilities are realised through object adapters that provide additional cooperative facilities and greater control over the supporting infrastructure. The outlined shared object service presented in this talk is closely related to an interface service that manages the cooperative presentation of shared information. The talk will conclude with a brief overview of the way in which traditional notions of sharing are exploited in defining shared user interface systems. *********************** Abstact ends. *********************** Gordon Joly Email: G.Joly@cs.ucl.ac.uk +441713807934 FAX +441713871397 Computer Science, University College London, Gower St., LONDON WC1E 6BT http://www.cs.ucl.ac.uk/people/gordo/ http://artaids.dcs.qmw.ac.uk:8001/ From rem-conf-request@es.net Mon Dec 12 07:20:11 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <09053-0@osi-west2.es.net>; Mon, 12 Dec 1994 07:14:51 -0800 Received: from gateway-gw.pictel.com by osi-west.es.net via ESnet SMTP service id <22051-0@osi-west.es.net>; Mon, 12 Dec 1994 07:14:40 +0000 Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA20673; Mon, 12 Dec 94 10:14:38 EST Received: from gateway-gw.pictel.com (gateway) by roadrunner.pictel.com (4.1/runner.910925.1) id AA29964; Mon, 12 Dec 94 10:14:36 EST Received: from NOTESSMTP.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA20670; Mon, 12 Dec 94 10:14:36 EST Return-Path: Received: by NOTESSMTP.pictel.com (IBM OS/2 SENDMAIL VERSION 1.3.2)/1.0) id AA0294; Mon, 12 Dec 94 10:15:22 -0800 Message-Id: <9412121815.AA0294@NOTESSMTP.pictel.com> Received: from PicTel with "Lotus Notes Mail Gateway for SMTP" id 52D25B9CF730DF1885256122005FF7AD; Mon, 12 Dec 94 10:15:21 To: Van Jacobson Cc: Bill Fink , berc , mccanne , rem-conf From: Rich Baker/PicTel Date: 11 Dec 94 12:28:17 EDT Subject: Re: feedback - h.261 mcast during IETF Mime-Version: 1.0 Content-Type: Text/Plain Hi Van: You wrote: >The blockiness in the plenary video was mostly due to the scene > being way too dark (Carl told me his cameras were giving lots of >trouble & the auto-iris on at least one seems to have died). >Since the vic h.261 encoder uses a fixed quantizer, this meant >that the little bit of the luminance dynamic range that was >being used covered just a few quantization levels which >translates into easily visible block artifacts. At some point >we hope to add either an adaptive quantizer to vic (but this is >computationally expensive) and/or a transmit "setup" button that >will expand to luminance signal from the camera/capture board to >cover the entire CCIR-601 dynamic range. In the meantime it's a >good idea to adjust the camera so that the scene coming out of >the capture board looks & stays fairly bright. I think you're partly right. Low light causes lots of camera noise in the video signal, which to a codec appears like changes in the scene. Most high-end codecs today include some form of temporal non-linear filtering to smooth out frame-to-frame changes in pixel luminance due to camera noise. Under low light conditions, this can dramatically improve frame rate and image quality, since the codec doesn't waste bits chasing meaningless noise. Furthermore, auto-iris is the nemesis of H.261. Each time a camera changes its iris, the entire scene changes brightness. Since H.261 can describe the picture only in terms of 8x8 blocks, every block must be updated to represent its new brightness. But at modest bit rates (say, 100 Kbit/s), it may take 5 to 10 frames or more to update every block. And even then, the blocks are only coarsely updated. The result? Tiling artifacts, until the codec can catch up. Unfortunately, by then a camera may auto-iris yet again... The only real solution to the auto-iris problem is to use a non-block oriented video coding technique. For example, hierarchical coding using a resolution pyramid structure avoids the problem, because each frame time a very low resolution picture capturing all the localized luminance changes can be sent with very low overhead. So the global effect of the iris change can be represented in just one frame time. This is a good reason why McCanne, et al., should invest some effort developing good hierarchical coding structures suitable for multicast protocols -- they can help improve even point-to-point video quality. -rich baker PictureTel Corp From rem-conf-request@es.net Mon Dec 12 07:29:52 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <09099-0@osi-west2.es.net>; Mon, 12 Dec 1994 07:23:27 -0800 Received: from gw1.att.com by osi-west.es.net via ESnet SMTP service id <22111-0@osi-west.es.net>; Mon, 12 Dec 1994 07:23:19 +0000 Received: by ig1.att.att.com id AA10293; Mon, 12 Dec 94 09:56:40 EST From: cae@iexist.att.com Received: from salt.lab5523 by iexist.att.com (4.1/SMI-4.1) id AA03555; Mon, 12 Dec 94 08:58:56 CST Received: by salt.lab5523 (4.1/SMI-4.0) id AA08438; Mon, 12 Dec 94 08:58:55 CST Date: Mon, 12 Dec 94 08:58:55 CST Message-Id: <9412121458.AA08438@salt.lab5523> To: rem-conf@es.net Subject: unsubscribe unsubscribe From rem-conf-request@es.net Mon Dec 12 08:19:15 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <09197-0@osi-west2.es.net>; Mon, 12 Dec 1994 08:13:05 -0800 Received: from koriel.Sun.COM by osi-west.es.net via ESnet SMTP service id <22501-0@osi-west.es.net>; Mon, 12 Dec 1994 08:12:54 +0000 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA03294; Mon, 12 Dec 94 08:12:50 PST Received: from jadeite.eng.sun.com by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21172; Mon, 12 Dec 94 08:13:49 PST Received: from valathar.eng.sun.com by jadeite.eng.sun.com (5.0/SMI-SVR4) id AA05941; Mon, 12 Dec 1994 08:13:20 +0800 Received: by valathar.eng.sun.com (5.x/SMI-SVR4) id AA08265; Mon, 12 Dec 1994 08:11:36 -0800 Date: Mon, 12 Dec 1994 08:11:36 -0800 From: speer@jadeite.Eng.Sun.COM (Michael Speer) Message-Id: <9412121611.AA08265@valathar.eng.sun.com> To: Toerless.Eckert@Informatik.Uni-Erlangen.de, mit@cs.tut.fi Subject: Re: SunVideo question Cc: rem-conf@es.net X-Sun-Charset: US-ASCII Content-Length: 2645 Toerless and Mit: The hardware support for DMA for the SunVideo Card was not added until recently. In fact, the Solaris 2.4 driver is the only driver that knows about the DMA mode. If DMA exists on a particular SunVideo card, then the Solaris 2.4 driver and software will take advantage of it. Otherwise, it's programmed I/O. Regards, Michael > From rem-conf-request@es.net Thu Dec 8 23:53:05 1994 > Return-Path: > From: Tsokkinen Mikko > To: Toerless Eckert > Cc: rem-conf@es.net > Subject: Re: SunVideo question > In-Reply-To: <199411290853.AA12891@faui43.informatik.uni-erlangen.de> > References: <199411290853.AA12891@faui43.informatik.uni-erlangen.de> > Content-Length: 1777 > X-Lines: 37 > > Toerless Eckert writes: > >Hi > > > >I was wondering if someone on this list could comment the following observation. > >Upon using the SunVideo board with solaris 2.4 on a ss20/612 a message > >is printed, telling me that "rtvc: DMA mode is not supported in this version > >of the hardware". I suppose this means that the SunVideo board is suspected > >to be able to do DMA mode but that this won't work with the board i have. > >I'd like to know if other people have made the same observation and > >what kind of throughput can be achieved with the SunVideo board (maybe > >this may be used as an indication if DMA is enabled or not). > > I have SS20/50 running Solaris2.3. I don't get any errors about the > DMA. I suspect it does not work with 60 MHz processors. > > >The following table contains the throughput i could measure with the > >SunVideo program that comes with solaris 2.4. The maximum throughput over > >the bus seem to be 3.6 MByte/sec (for uncompressed RGB color) and this doesn't > >look very much like DMA to me (i.e.: the old VideoPix graphics board that > >surely had no DMA would achieve the same throughput). > > The SunVideo program shows the maximum throughput using 768x576 PAL > and direct output without local display is around 40 Mbps (or 5 MBps). > The frame rate is around 4. > > >I wanted to buy another couple of SunVideo boards, but if this could mean for > >example that buying now would give me yet another board without DMA and > >two month later a board capable of DMA would be available, i'd better wait. > > I cannot comment whether there will be a new version. I suspect your > card works just fine in a 50 or 512 machine. > > Mikko Tsokkinen > > Digital Media Institute, Tampere University of Technology > Research Assistant - Project FASTER > Distributed Multimedia Applications over ATM-Network > From rem-conf-request@es.net Mon Dec 12 10:05:46 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <09600-0@osi-west2.es.net>; Mon, 12 Dec 1994 09:56:46 -0800 Received: from mento.oit.unc.edu by osi-west.es.net via ESnet SMTP service id <23494-0@osi-west.es.net>; Mon, 12 Dec 1994 09:56:12 +0000 Received: by mento.oit.unc.edu (NeXT-1.0 (From Sendmail 5.52)/TAS/11-16-88) id AA17839; Mon, 12 Dec 94 12:56:09 EST Date: Mon, 12 Dec 1994 12:56:08 -0500 (EST) From: Paul Jones To: rem-conf@es.net Cc: sungroup@sunsite.unc.edu, wxyc@sunsite.unc.edu Subject: WXYC and MBONE, etc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I am not a member of this conference, but I have had a message forwarded to me that mentions our project of cybercasting WXYC on SunSITE.unc.edu. At the risk of restating other reasonable responses to Henning Schulzrinne , let me set a few things straight. First using CU-SeeMe to cybercast in no way affects the MBONE preformance. vat can act as a CU-SeeMe receiver, but it does not use MBONE nor does it use any part of the multicasting technology in doing so. We choose CU-SeeMe explicitly because of its low bandwidth usage and the fact that it only creates traffic when connected to another host. Then that traffic exists only on links to that host. Our experiements show that by sending audio only using CU-SeeMe that very little bandwidth is used. Your own traces and monitors can verify this if you wish. Further the reflector technology of CU-SeeMe allows us to place reflectors at or near very busy sites thus furhter reducing traffic. Additionally we can and will restrict the number of simultaneous accesses if we can detect any problems in excessive network traffic. I appologize for any incorrect impressions that our press release might have caused in its mention of MBONE. For more about CU-SeeMe see: http://sunsite.unc.edu/cisco/photo-arch.html Note to those of you connecting to WXYC: CU-SeeMe takes a short while to anticipate the correct packet flow and cache the sound accordingly. Expect a few seconds of silence and noise before you begin to receive what might be music. ============================================================================ Paul Jones Paul_Jones@unc.edu voice:(919) 962-6501 fax:(919) 962-5664 Office FOR Information Technology School of Journalism and Mass Communication School of Information and Library Science University of North Carolina My other office has a window From rem-conf-request@es.net Mon Dec 12 13:11:19 1994 Received: from osi-west.es.net by osi-west2.es.net via ESnet SMTP service id <10248-0@osi-west2.es.net>; Mon, 12 Dec 1994 13:04:31 -0800 Received: from shiva.jussieu.fr by osi-west.es.net via ESnet SMTP service id <26140-0@osi-west.es.net>; Mon, 12 Dec 1994 13:04:20 +0000 Received: from moka.ccr.jussieu.fr (moka.ccr.jussieu.fr [134.157.1.23]) by shiva.jussieu.fr (8.6.9/jtpda-5.0) with ESMTP id WAA17871 for ; Mon, 12 Dec 1994 22:04:01 +0100 Received: from [134.157.81.160] (ligne10.ext.jussieu.fr [134.157.81.160]) by moka.ccr.jussieu.fr (8.6.9/jtpda-5.0) with SMTP id WAA76367 for ; Mon, 12 Dec 1994 22:03:57 +0100 Message-Id: <199412122103.WAA76367@moka.ccr.jussieu.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora F1.4.3 Date: Mon, 12 Dec 1994 22:06:25 +0000 To: rem-conf@es.net From: guidon@ccr.jussieu.fr (Jacques.Guidon) Subject: unsubscribe unsubscribe Jacques GUIDON LID - UNIVERSITE PARIS 7 2 Place Jussieu 75005 PARIS - FRANCE Tel: +33 1 44 27 78 28 Fax: +33 1 44 27 57 40 email: guidon@ccr.jussieu.fr OU guidon@nuri.inria.fr From rem-conf-request@es.net Tue Dec 13 05:14:53 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <02418-0@osi-west.es.net>; Tue, 13 Dec 1994 02:14:22 +0000 Received: from muridae.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 13 Dec 1994 10:13:53 +0000 To: stevek@scorpio.arc.nasa.gov, stevek@arc.nasa.gov cc: rem-conf@es.net Subject: NASA Select In-reply-to: Your message of "Mon, 05 Dec 94 13:41:03 PST." <941205134103.19107@euclid> Date: Tue, 13 Dec 94 10:13:12 +0000 From: Gordon Joly Can anybody help? s=NASA-Ames/K-12(audio) s=NASA-Ames/K-12(video) I am unable to find a reference to these MBONE or Rem-Conf. Or a reference to hhtp. Gordon Joly Email: G.Joly@cs.ucl.ac.uk +441713807934 FAX +441713871397 Computer Science, University College London, Gower St., LONDON WC1E 6BT http://www.cs.ucl.ac.uk/people/gordo/ http://artaids.dcs.qmw.ac.uk:8001/ From rem-conf-request@es.net Tue Dec 13 05:47:36 1994 Received: from sun2.nsfnet-relay.ac.uk by osi-west.es.net via ESnet SMTP service id <02697-0@osi-west.es.net>; Tue, 13 Dec 1994 02:47:06 +0000 Via: uk.ac.rutherford.informatics; Tue, 13 Dec 1994 10:46:22 +0000 Received: from bingo by inf.rl.ac.uk; Tue, 13 Dec 94 10:46:01 GMT Date: Tue, 13 Dec 1994 10:46:00 +0000 From: ijj@informatics.rutherford.ac.uk Message-Id: <9412131046.AA23070@bingo> To: speer@jadeite.Eng.Sun.COM Subject: Re: SunVideo question Cc: rem-conf@es.net, Toerless.Eckert@Informatik.Uni-Erlangen.de, mit@cs.tut.fi X-Sun-Charset: US-ASCII Content-Length: 1501 > From rem-conf-request@es.net Mon Dec 12 19:36:13 1994 > From: speer@COM.Sun.Eng.jadeite (Michael Speer) > To: Toerless.Eckert@de.Uni-Erlangen.Informatik, mit@cs.tut.fi > Subject: Re: SunVideo question > > Toerless and Mit: > > The hardware support for DMA for the SunVideo Card was not added until > recently. In fact, the Solaris 2.4 driver is the only driver that knows > about the DMA mode. If DMA exists on a particular SunVideo card, then > the Solaris 2.4 driver and software will take advantage of it. Otherwise, > it's programmed I/O. > > Regards, > Michael > Michael, The implication seems to be, as Toerless and Mit were suggesting, that only later SunVideo cards support DMA. If so, one would assume that this gives (in a Solaris 2.4 system) a performance advantage over older cards without DMA, and is thus a Good Thing... How can we tell in advance (e.g. before buying) if a SunVideo card supports DMA? Is there a range of serial numbers for cards with DMA? If one were about to order a SunVideo card, one might like to know in advance what one is getting. If I find that the SunVideo card which I've just bought doesn't do DMA, can I return it to SunExpress for a later model with DMA? -- "Nudist welfare man's wife fell for Chinese hypnotist >from the Co-Op bacon counter" - News of the World headline Ian Johnson Internet: ijj@inf.rl.ac.uk Rutherford Appleton Laboratory, World-Wide Web: Chilton, Didcot, Oxon OX11 0QX. http://web.inf.rl.ac.uk/people/ijj.html From rem-conf-request@es.net Tue Dec 13 07:44:44 1994 Received: from faui45.informatik.uni-erlangen.de by osi-west.es.net via ESnet SMTP service id <03403-0@osi-west.es.net>; Tue, 13 Dec 1994 04:43:28 +0000 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA21321 (5.65c-6/7.3w-FAU); Tue, 13 Dec 1994 13:42:43 +0100 Received: from faui45r.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA29038 (5.65c-6/7.3m-FAU); Tue, 13 Dec 1994 13:42:38 +0100 From: Toerless Eckert Message-Id: <199412131242.AA29038@faui43.informatik.uni-erlangen.de> Subject: Re: SunVideo question To: ijj@informatics.rutherford.ac.uk Date: Tue, 13 Dec 1994 13:42:27 +0100 (MET) Cc: speer@jadeite.Eng.Sun.COM, rem-conf@es.net, Toerless.Eckert@Informatik.Uni-Erlangen.de, mit@cs.tut.fi In-Reply-To: <9412131046.AA23070@bingo> from "ijj@informatics.rutherford.ac.uk" at Dec 13, 94 10:46:00 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 > Is there a range of serial numbers for cards with DMA? If one were about to > order a SunVideo card, one might like to know in advance what one is getting. > If I find that the SunVideo card which I've just bought doesn't do DMA, can I > return it to SunExpress for a later model with DMA? The answer from sun on that question was that you can see from the bootstrap procedure if DMA is supported, use "boot -v" to get the appropirate messages. Toerless From rem-conf-request@es.net Tue Dec 13 11:03:15 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <04808-0@osi-west.es.net>; Tue, 13 Dec 1994 08:02:30 +0000 Received: from muridae.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 13 Dec 1994 15:59:35 +0000 To: tom@computing.lancaster.ac.uk CC: rem-conf@es.net, mice-nsc@cs.ucl.ac.uk Subject: Re: MICE Seminar: Tuesday 13th December at 14:00 UTC. Date: Tue, 13 Dec 94 15:58:52 +0000 From: Gordon Joly My apologies. The wb was started by hand (to include the large PostScript files) and I forgot to set the ttl at 127. The slides will appear today in http://www.cs.ucl.ac.uk/mice/seminars/archive/ Gordon Joly Email: G.Joly@cs.ucl.ac.uk +441713807934 FAX +441713871397 Computer Science, University College London, Gower St., LONDON WC1E 6BT http://www.cs.ucl.ac.uk/people/gordo/ http://artaids.dcs.qmw.ac.uk:8001/ From rem-conf-request@es.net Tue Dec 13 12:54:16 1994 Received: from scorpio.arc.nasa.gov by osi-west.es.net via ESnet SMTP service id <06207-0@osi-west.es.net>; Tue, 13 Dec 1994 09:53:28 +0000 Received: by scorpio.arc.nasa.gov (931110.SGI/911001.SGI) for rem-conf@es.net id AA11698; Tue, 13 Dec 94 09:46:53 -0800 Date: Tue, 13 Dec 94 09:46:53 -0800 From: stevek@scorpio.arc.nasa.gov (Steve Kyramarios) Message-Id: <9412131746.AA11698@scorpio.arc.nasa.gov> Apparently-To: rem-conf@es.net NASA-Ames Research Center will be broadcasting the "Live from Antarcticafrom the local NASA-Select feed. The program is in support of the Agencies K-12 project. The program will be broadcasted at a ttl of 128. Broadcast dates are as followed: December 13, 1994 at 11:00am Pacific December 15, 1994 at 1:00pm Pacific January 10, 1994 at 2:30pm Pacific January 19, 1994 at 10:00am Pacific All broadcasts will be approximately 1 hour in length. All comments should be addressed to stevek@scorpio.arc.nasa.gov Note: This is our first broadcast from this location, so all comments are wele. Thanks...... From rem-conf-request@es.net Tue Dec 13 15:43:31 1994 Received: from colorado.gard.puc.cl by osi-west.es.net via ESnet SMTP service id <08251-0@osi-west.es.net>; Tue, 13 Dec 1994 12:42:36 +0000 Received: by colorado.gard.puc.cl (1.38.193.3/16.2) id AA01538; Tue, 13 Dec 94 17:39:25 -0400 From: Marcos Prats Subject: MBONE question To: rem-conf@es.net Date: Tue, 13 Dec 94 17:39:23 SAT Mailer: Elm [revision: 70.85] Hello, I am trying to use the MBONE softwares to establish a multicast video confference and i need to know if i have keep running "mrouted" deamon in all the machines that are in the confference or just one of them?? Should i run it with some arguments??? which one?? thank you very much! From rem-conf-request@es.net Tue Dec 13 15:51:36 1994 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by osi-west.es.net via ESnet SMTP service id <08344-0@osi-west.es.net>; Tue, 13 Dec 1994 12:51:00 +0000 Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU [132.236.199.117]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id PAA08878; Tue, 13 Dec 1994 15:50:47 -0500 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 Dec 1994 15:50:53 -0500 To: Paul Jones From: Scott Brim Subject: Re: WXYC and MBONE, etc. Cc: rem-conf@es.net, sungroup@sunsite.unc.edu, wxyc@sunsite.unc.edu Paul, IMHO there are three conditions which should guide whether to use the mbone tools or CU-SeeMe. (1) how well deployed pruning is in the mbone (currently not well but improving); (2) how many simultaneous receivers you expect to have; (3) how good a reflector group you can establish to cascade the flows (related to #2). I guess I can add a fourth: how likely it is that your target audience has workstations which support the mbone tools. I hadn't realized that you were going to establish subsidiary reflectors and limit access to the primary source. Thank goodness. My concern, and embarrassment, comes when people establish a reflector and then encourage everyone, worldwide, to connect to it. CU-SeeMe might not use mbone tunnels but it does affect mbone performance because it uses the same underlying pipes. It affects WWW etc. access to Sunsite, perhaps even more (since they use TCP). > My other office has a window Nice picture of your family(??). ...Scott From rem-conf-request@es.net Tue Dec 13 20:28:19 1994 Received: from mento.oit.unc.edu by osi-east.es.net via ESnet SMTP service id <25421-0@osi-east.es.net>; Tue, 13 Dec 1994 17:27:58 +0000 Received: by mento.oit.unc.edu (NeXT-1.0 (From Sendmail 5.52)/TAS/11-16-88) id AA23118; Tue, 13 Dec 94 20:27:46 EST Date: Tue, 13 Dec 1994 20:27:46 -0500 (EST) From: Paul Jones To: Scott Brim Cc: rem-conf@es.net, sungroup@sunsite.unc.edu, wxyc@sunsite.unc.edu Subject: Re: WXYC and MBONE, etc. In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > CU-SeeMe might not use mbone tunnels but it does affect mbone > performance because it uses the same underlying pipes. It affects WWW > etc. access to Sunsite, perhaps even more (since they use TCP). With all due respect to Scott and the members of this group, I confess that while our tests of CU-SeeMe showed very little network load incurred as a result of up to 20 connections, any progam sending packets does place some network load. My point was/is that, thanks to the great job that Scott and his pals at Cornell have done, CU-SeeMe is a much lighter protocol than even I would have expected (used as audio only). It is certainly much lighter than other (true) MBONE traffic. I don't even need a monitor to show MBONE load all I need to do is to try and use the subnet. SunSITE's T-1 was already at 99% before we added WXYC; we may be self-regulating due to our pipe ;-> One other point, we are trying to be responsible and would love to hear about it if we are causing any network problems for anyone any where. Of course, we'd be glad to hear from folks who have more than one or two folks connecting to WXYC and to discuss a reflector network with them. ============================================================================ Paul Jones Paul_Jones@unc.edu voice:(919) 962-6501 fax:(919) 962-5664 Office FOR Information Technology School of Journalism and Mass Communication School of Information and Library Science University of North Carolina My other office has a window From rem-conf-request@es.net Tue Dec 13 20:34:07 1994 Received: from mento.oit.unc.edu by osi-east.es.net via ESnet SMTP service id <25537-0@osi-east.es.net>; Tue, 13 Dec 1994 17:33:46 +0000 Received: by mento.oit.unc.edu (NeXT-1.0 (From Sendmail 5.52)/TAS/11-16-88) id AA23140; Tue, 13 Dec 94 20:33:38 EST Date: Tue, 13 Dec 1994 20:33:37 -0500 (EST) From: Paul Jones To: Scott Brim Cc: rem-conf@es.net, sungroup@sunsite.unc.edu, wxyc@sunsite.unc.edu Subject: Re: WXYC and MBONE, etc. In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 13 Dec 1994, Scott Brim wrote: > Paul, IMHO there are three conditions which should guide whether to use > the mbone tools or CU-SeeMe. (1) how well deployed pruning is in the > mbone (currently not well but improving); (2) how many simultaneous > receivers you expect to have; (3) how good a reflector group you can > establish to cascade the flows (related to #2). > I guess I can add a fourth: how likely it is that your target audience > has workstations which support the mbone tools. Yup that and low-bandwidth and the fact that we might be able to distribute the netload with reflectors figured into our choice of CU-SeeMe over MBONE. Most of our campus do not have MBONE capable hosts. > > I hadn't realized that you were going to establish subsidiary > reflectors and limit access to the primary source. Thank goodness. My > concern, and embarrassment, comes when people establish a reflector and > then encourage everyone, worldwide, to connect to it. We may be crazy but we are not fools (entirely) > > CU-SeeMe might not use mbone tunnels but it does affect mbone > performance because it uses the same underlying pipes. It affects WWW > etc. access to Sunsite, perhaps even more (since they use TCP). Okay okay I overstated I understand TCP I recant word none and substitute not very much. > > > My other office has a window > > Nice picture of your family(??). Yup although a bit dark on Sally. Tucker was his regular joyful self. Hope you're doing well. You folks did a great job on CU-SeeMe ============================================================================ Paul Jones Paul_Jones@unc.edu voice:(919) 962-6501 fax:(919) 962-5664 Office FOR Information Technology School of Journalism and Mass Communication School of Information and Library Science University of North Carolina My other office has a window From rem-conf-request@es.net Tue Dec 13 22:51:57 1994 Received: from trapdoor.dstc.edu.au by osi-east.es.net via ESnet SMTP service id <27573-0@osi-east.es.net>; Tue, 13 Dec 1994 19:51:16 +0000 Received: from magenta.dstc.edu.au (magenta.dstc.edu.au [130.102.176.31]) by trapdoor.dstc.edu.au (8.6.9/8.6.9) with ESMTP id NAA08519; Wed, 14 Dec 1994 13:51:12 +1000 Received: from localhost (frank@localhost [127.0.0.1]) by magenta.dstc.edu.au (8.6.9/8.6.9) with SMTP id NAA02545; Wed, 14 Dec 1994 13:51:11 +1000 Message-Id: <199412140351.NAA02545@magenta.dstc.edu.au> X-Authentication-Warning: magenta.dstc.edu.au: Host localhost didn't use HELO protocol To: rem-conf@es.net Subject: CRC Seminar, Thursday 15th December 13:30-17:00 Cc: jason@magenta.dstc.edu.au, leith@magenta.dstc.edu.au, frank@magenta.dstc.edu.au X-Face: $i3=cU,{-9g'SjP-^R-~2oi.A26-jLw|V2XGTfYVu&L_:~k{jP>il&q_mUiGgW4X)1(1WW% k[hpAeT%PkSi,v.(P1BqsN'C8y{2w'DBM2L7!UEJ}=Vs%F#B>.UFtLu2=h&2T/==bE[Z;ji/FaM]`v 4,f#`l>"XrZSaku`nV){zxtZfz9My^v"Kd_rZ^"QTh^{MreV;}*o#Xq_1RB-o'E1f##l*(zy)jqm;* '*kC;%Mul&IcqjVAZ=4l^w7D5PO Date: Wed, 14 Dec 1994 13:51:09 +1000 From: Francis Edwards The CRC for Distributed Systems Technology will be conducting a multicast seminar for all CRC and seconded staff on Thursday 15th December. The transmission will be sourced from CRC HQ at the University of Queensland and involve sites at UTS Sydney, CSIRO Melbourne and Telecom Research Labs. We will be transmitting pcm2 audio and whiteboard slides with a ttl of 63, i.e. limited to Australia. No video stream will be present due to bandwidth constraints at some sites. The times are: 15:30-17:00 15 Dec (Local) 3:30-7:00 15 Dec (GMT) Please let me know if there are problems... Thanks, Frank ----- Francis Edwards R&D Engineer frank@dstc.edu.au CRC for Distributed Systems Technology Tel: +61 7 365 4310 Gehrmann Laboratories Fax: +61 7 365 4399 The University of Queensland Q 4072 Australia ----- From rem-conf-request@es.net Wed Dec 14 00:33:11 1994 Received: from tampico.cso.uiuc.edu by osi-west.es.net via ESnet SMTP service id <01666-0@osi-west.es.net>; Tue, 13 Dec 1994 21:32:33 +0000 Received: from [192.17.16.21] (archer.isdn.uiuc.edu) by tampico.cso.uiuc.edu with SMTP id AA22147 (5.67b/IDA-1.5 for ); Tue, 13 Dec 1994 23:32:21 -0600 X-Sender: kline@tampico.cso.uiuc.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 Dec 1994 23:32:29 -0600 To: Paul Jones From: kline@uiuc.edu (Charley Kline) Subject: Re: WXYC and MBONE, etc. Cc: rem-conf@es.net At 8:27 PM 12/13/94, Paul Jones wrote: >With all due respect to Scott and the members of this group, I confess >that while our tests of CU-SeeMe showed very little network load incurred >as a result of up to 20 connections, any progam sending packets does place >some network load. My point was/is that, thanks to the great job that >Scott and his pals at Cornell have done, CU-SeeMe is a much lighter >protocol than even I would have expected (used as audio only). It is >certainly much lighter than other (true) MBONE traffic. I don't even need >a monitor to show MBONE load all I need to do is to try and use the >subnet. Paul, you do not understand how audio is transported over the net. The compression used by the CUSM audio code (which was written by me), while you may call it lightweight, is not adaptive at all and will consume the advertised bandwidth (32kb/s if you select the best coding currently provided) per connection no matter what other traffic is present on the net. If UNC's T1 was "99% loaded" (which I doubt) before you began your broadcasting, then it is the TCP-based traffic, such as WWW, mail, and FTP, that is suffering at the expense of WXYC, because TCP operates on the available bit rate and will consume only what is available. Obviously "any program sending packets produces some network load." The point here is that one-way transmission of constant bit-rate data such as audio is not sensitive to load problems. Not only does performance of other network applications suffer, but when links get busy enough to drop packets, everyone trying to listen to the radio station gets broken up audio which is useless to hear. You will be surprised to hear that the audio codings used by the MBONE tools are the EXACT SAME as those provided by Maven and CUSM. I believe your subjective observation of the amount of load generated by multiple unicast streams vs a single multicast stream is flawed. -- Charley Kline kline@uiuc.edu UIUC Network Architect (217) 333-3339 Nobody ever forgets anything. The secret is learning to live with remembering. From rem-conf-request@es.net Wed Dec 14 01:51:18 1994 Received: from jaring.my by osi-west.es.net via ESnet SMTP service id <02227-0@osi-west.es.net>; Tue, 13 Dec 1994 22:49:43 +0000 Received: from srb.UUCP by jaring.my with UUCP id AA12356 (5.67a/IDA-1.5 for es.net!rem-conf); Wed, 14 Dec 1994 14:49:31 +0800 Message-Id: <199412140649.AA12356@jaring.my> Received: from srb by srb.pl.my (UUPC/extended 1.12b) with UUCP; Tue, 13 Dec 1994 18:07:46 GMT From: Saravana Ram Balakrishnan To: rem-conf@es.net Date: Tue, 13 Dec 1994 18:07:45 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: unsubscribe Reply-To: Saravana Ram Priority: normal X-Mailer: PMail v3.0 (R1a) unsubscribe -- Saravana Ram Balakrishnan Tel: +60-3-255-9841 ram@srb.pl.my From rem-conf-request@es.net Wed Dec 14 04:43:02 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <03376-0@osi-west.es.net>; Wed, 14 Dec 1994 01:22:00 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 14 Dec 1994 09:21:20 +0000 To: Paul Jones cc: Scott Brim , rem-conf@es.net, sungroup@sunsite.unc.edu, wxyc@sunsite.unc.edu Subject: Re: WXYC and MBONE, etc. In-reply-to: Your message of "Tue, 13 Dec 94 20:27:46 EST." Date: Wed, 14 Dec 94 09:21:15 +0000 Message-ID: <875.787396875@cs.ucl.ac.uk> From: Jon Crowcroft >> CU-SeeMe might not use mbone tunnels but it does affect mbone >> performance because it uses the same underlying pipes. It affects WWW >> etc. access to Sunsite, perhaps even more (since they use TCP). > >With all due respect to Scott and the members of this group, I confess >that while our tests of CU-SeeMe showed very little network load incurred >as a result of up to 20 connections, any progam sending packets does place >some network load. If you ran 20 CuSeeMe calls across the UK US link. yo uwould severly degrade our mbone and unicast performance one thing you must learn about the internet and the mbone is that no single person can determine whether program/protocol X will have a benficial or harmful effect - only the community can say that by distributed, careful testing.... however, it is obvioius to me that unless you have a distributed set of CuSeeMe reflectors, very carefully organised (along the lines of emerging WWW cache hierarchy, or the archie server hierarchy, or the DNS one) and the reflectors were to use multicast between themselves, CUSeeME cannot hoe to scale to the mbone application group sizes.... jon From rem-conf-request@es.net Wed Dec 14 05:19:56 1994 Received: from cancer.ucs.ed.ac.uk by osi-west.es.net via ESnet SMTP service id <03989-0@osi-west.es.net>; Wed, 14 Dec 1994 02:19:26 +0000 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.9/8.6.9) with ESMTP id KAA17382; Wed, 14 Dec 1994 10:18:51 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id KAA07335; Wed, 14 Dec 1994 10:18:49 GMT Date: Wed, 14 Dec 1994 10:18:49 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Jon Crowcroft cc: Paul Jones , Scott Brim , rem-conf@es.net, sungroup@sunsite.unc.edu, wxyc@sunsite.unc.edu Subject: Re: WXYC and MBONE, etc. In-Reply-To: <875.787396875@cs.ucl.ac.uk> Message-ID: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-URL: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 14 Dec 1994, Jon Crowcroft wrote: > however, it is obvioius to me that unless you have a distributed set > of CuSeeMe reflectors, very carefully organised (along the lines of > emerging WWW cache hierarchy, or the archie server hierarchy, or the > DNS one) and the reflectors were to use multicast between themselves, > CUSeeME cannot hoe to scale to the mbone application group sizes.... So to clarify this, you need to setup a "web" of CUSeeMe reflectors in order to spread the traffic around as evenly as possible. To get the optimum spread you, therefore, approach the point where you recreate the entire MBONE with CUSeeMe reflectors. It therefore seems sensible to wait for multicast to appear in the IP implementations for the Mac and PC before too much widespread (wide-area spread?) use is made of CUSeeMe and ilk. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From rem-conf-request@es.net Wed Dec 14 05:34:30 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <04093-0@osi-west.es.net>; Wed, 14 Dec 1994 02:33:44 +0000 Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 14 Dec 1994 10:32:15 +0000 To: Graeme.Wood@ucs.edinburgh.ac.uk cc: Paul Jones , Scott Brim , rem-conf@es.net, sungroup@sunsite.unc.edu, wxyc@sunsite.unc.edu Subject: Re: WXYC and MBONE, etc. In-reply-to: Your message of "Wed, 14 Dec 94 10:18:49 GMT." Date: Wed, 14 Dec 94 10:32:12 +0000 Message-ID: <710.787401132@cs.ucl.ac.uk> From: Jon Crowcroft >So to clarify this, you need to setup a "web" of CUSeeMe reflectors in >order to spread the traffic around as evenly as possible. To get the >optimum spread you, therefore, approach the point where you recreate the >entire MBONE with CUSeeMe reflectors. >It therefore seems sensible to wait for multicast to appear in the IP >implementations for the Mac and PC before too much widespread (wide-area >spread?) use is made of CUSeeMe and ilk. not necessarily - the Cu-Seem`Me model of client calls, is more appropirate to some users' applicaitons of conferencing the cornell people have some good arguments for the model, but yes, multicast for distribution of data at some point in scaling is indicated jon From rem-conf-request@es.net Wed Dec 14 05:53:37 1994 Received: from rx7.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <04183-0@osi-west.es.net>; Wed, 14 Dec 1994 02:52:53 +0000 Received: by rx7.ee.lbl.gov for rem-conf@es.net (5.65/1.44r) id AA26457; Wed, 14 Dec 94 02:55:51 -0800 Message-Id: <9412141055.AA26457@rx7.ee.lbl.gov> To: Gordon Joly Cc: tom@comp.lancs.ac.uk, rem-conf@es.net, mice-nsc@cs.ucl.ac.uk Subject: Re: wb postscript size limit In-Reply-To: Your message of Tue, 13 Dec 94 15:58:52 GMT. Date: Wed, 14 Dec 94 02:55:49 PST From: Van Jacobson Gordon, > The wb was started by hand (to include the large PostScript > files) and I forgot to set the ttl at 127. I sympathize with the postscript import problems & the desire to bump up the limit as a last minute "quick hack". But, if you have a few minutes to spend on pre-processing the postscript with some widely available tools, you can almost always reduce the size to something below the limit & the result is *much* better for the speaker, the listeners & the net. Appended is a note I wrote a few months ago describing why the limit exists & what you might do to live with it. - Van ------------------------------ Wb and the 32K PostScript filesize limit ---------------------------------------- Although it seems arbitrary and annoying, the 32k postscript filesize limit in wb wasn't put in to annoy you -- it was added because experience has shown that the time to actually deliver large ps files to all (or most of) a conference's participants goes up like the square of the file size. Wb rate-limits sends so that a wb session costs no more than an audio session (64kb/s). At 64kb/s, a 1MB postscript file takes over two minutes to send even if there are no errors & realistically takes 5-10 minutes. A speaker rarely wants to take a five minute break each time she moves to a new slide. By contrast, a 32KB file is typically delivered in 5-10 sec. and <=16KB in 2-3 sec. 2-3 sec. is a normal speaking pause between slides & 5-10 sec. is tolerable, especially if the speaker is aware that receivers will be seeing the slides after a delay & paces the talk appropriately. It is unfortunately the case the many programs produce huge postscript files. This seems to be entirely due to laziness & stupidity on the part of the companies writing these programs (e.g., Microsoft, Apple) and it is usually easy to convert their garbage postscript into a far more compact postscript. You have two choices: (1) run the file through pssplit to split the pages into separate files & lz compress those files and/or (2) run the file through Adobe's distill. Pssplit is part of the wbimport distribution (ftp.ee.lbl.gov: conferencing/wb/wbimport.tar.Z if you don't already have it). If you are giving a presentation, you probably want to use wbimport to sequence through your slides. Wbimport lets the speaker easily jump back & forth between slides (by just clicking on the slide name in the wbimport window) & it takes care of forcing all the participants to change to the appropriate page when the speaker moves to a new slide (when doing presentations `by hand', speakers usually forget that scrolling the wb window is a *local* operation and you have to draw on a page to force other participants to change to that page). Wbimport requires that each page be a separate file. Pssplit will split a postscript file containing multiple pages into one-file-per-page. It can also do the level-2 postscript version of Lempel-Ziv compression on the pages as it splits them. This usually makes the pages <32K. For example, say your slides are on file "myslides.ps". To split & compress the pages do: # it helps to leave all the pages in one subdirectory mkdir myslides; cd myslides # each page becomes file "pNN.ps" where NN is page number pssplit -v -lz ../myslides.ps # create a slide list for wbimport ls *.ps > slides The "-v" flag to pssplit will cause it to print the size of each page as it's split. (This just saves you doing an "ls -l" to check if anything is >32K). At this point, I usually run a local wb for a quick check: # start a local wb in the background wb localhost/5555 & # wait for the wb to come up then start wbimport with these slides wbimport slides & (Then just sequence through the slides by clicking "next" in the wbimport window & make sure all the slides image correctly with no complaints from wb or the postscript interpreter). When it comes time to give the talk, start wb in the usual way (i.e., via double clicking on the appropriate sd entry) then cd to the directory containing your slides & start wbimport as above: cd myslides wbimport slides & You *must* start wbimport *after* starting wb. Then just give your talk, clicking on "next" or the slide name in the wbimport window whenever you want to change slides. If the pages are still too large even after "pssplit -lz", or if pssplit won't handle the file because it's not Adobe DSC conformant, you might want to try Glen Reid's distill. Distill will convert the huge preambles associated with truly awful postscript (e.g., anything from Apple or Microsoft) into something both compact & DSC conformant. Distill (still.ps) is available on ftp.adobe.com & there's a recent version on ftp.ee.lbl.gov in conferencing/wb/still.ps. To use it, assuming that you use gs as your postscript interpreter, do: gs still.ps (myslides.ps)distill ^D If Display PostScript is your postscript interpreter do: dpsexec (still.ps)(r)file cvx (myslides.ps)distill ^D This should produce a 'distilled' version of myslides.ps on myslides.psx. Then run pssplit as above but on myslides.psx instead of myslides.ps. You shouldn't use distill with gs unless you have gs set up to use the Adobe fonts -- distill uses font metrics when constructing the distilled file & the metrics of fonts distributed with gs are different than Adobe's. This will make the character spacing on the distilled slides slightly weird. ps- Though it should be obvious from the above, wbimport, pssplit, etc., are tools for speakers to use. None of the other particpants need to be aware of them & no one but the speaker in some wb session should be running wbimport. From rem-conf-request@es.net Wed Dec 14 08:25:32 1994 Received: from stroma.dcs.ed.ac.uk by osi-west.es.net via ESnet SMTP service id <01397-0@osi-west.es.net>; Wed, 14 Dec 1994 05:24:32 +0000 Received: from tulm.dcs.ed.ac.uk by dcs.ed.ac.uk id aa16636; 14 Dec 94 12:56 GMT Message-Id: <5487.9412141256@tulm.dcs.ed.ac.uk> Received: from dcs.ed.ac.uk by tulm.dcs.ed.ac.uk; Wed, 14 Dec 1994 12:56:24 GMT To: rem-conf@es.net Cc: ajs@dcs.ed.ac.uk Subject: Computer Theory talks Date: Wed, 14 Dec 1994 12:56:15 +0000 From: Alastair Scobie content-length: 1334 On the 15th and 16th December the Department of Computer Science of the University of Edinburgh is celebrating the 60th birthdays of two of its eminent professors - Robin Milner and Rod Burstall. A series of talks by current and previous colleagues will be given to present their work and achievements, not only in the past, but also current work. The talks will be broadcast on the Mbone, details below: THURSDAY 15TH DECEMBER ("ROBIN'S DAY") 09.30 - 09.45 Gordon Plotkin: Welcome and Introduction to Robin's Work 09.45 - 11.00 Chris Wadsworth: LCF: A Logic for Computable Functions 11.30 - 12.45 Mads Tofte: The ML Programming Language 14.00 - 15.15 Matthew Hennessy: CCS: The Calculus of Communicating Systems 15.45 - 17.00 David Walker: The pi-calculus FRIDAY 16TH DECEMBER ("ROD'S DAY") 09.30 - 09.45 Gordon Plotkin: Welcome and Introduction to Rod's Work 09.45 - 10.45 Robin Popplestone: Robotics and POP-2 11.15 - 12.15 John Darlington: Program Transformation 13.30 - 14.30 Dave MacQueen: Language Design 15.00 - 16.00 David Rydeheard: Category Theory 16.00 - 17.00 Randy Pollack: Computer Aided Formal Reasoning All times above are GMT and the sessions will be advertised via the Session Directory. Any comments welcome to ajs@dcs.ed.ac.uk Alastair Scobie Computer Science Edinburgh University From rem-conf-request@es.net Wed Dec 14 09:39:55 1994 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by osi-west.es.net via ESnet SMTP service id <02094-0@osi-west.es.net>; Wed, 14 Dec 1994 06:38:43 +0000 Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU [132.236.199.117]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id JAA23772; Wed, 14 Dec 1994 09:32:46 -0500 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 Dec 1994 09:32:52 -0500 To: Jon Crowcroft From: Scott Brim Subject: Re: WXYC and MBONE, etc. Cc: Graeme.Wood@ucs.edinburgh.ac.uk, Paul Jones , rem-conf@es.net, sungroup@sunsite.unc.edu, wxyc@sunsite.unc.edu At 5:32 AM 12/14/94, Jon Crowcroft wrote: >the cornell people have some good arguments for the model, but yes, >multicast for distribution of data at some point in scaling is >indicated Right. I think the only thing we might disagree on is the usefulness of "reflectors". I think it's worth following that path for a while. I don't have clear enough vision yet to agree with those who think they are a wart on the nose of progress, etc. -- although they might be. ...Scott From rem-conf-request@es.net Wed Dec 14 09:57:36 1994 Received: from cancer.ucs.ed.ac.uk by osi-west.es.net via ESnet SMTP service id <02188-0@osi-west.es.net>; Wed, 14 Dec 1994 06:56:50 +0000 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.9/8.6.9) with ESMTP id OAA20020; Wed, 14 Dec 1994 14:56:16 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id OAA08063; Wed, 14 Dec 1994 14:56:14 GMT Date: Wed, 14 Dec 1994 14:56:14 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Scott Brim cc: Jon Crowcroft , Paul Jones , rem-conf@es.net, sungroup@sunsite.unc.edu, wxyc@sunsite.unc.edu Subject: Re: WXYC and MBONE, etc. In-Reply-To: Message-ID: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-URL: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 14 Dec 1994, Scott Brim wrote: > At 5:32 AM 12/14/94, Jon Crowcroft wrote: > >the cornell people have some good arguments for the model, but yes, > >multicast for distribution of data at some point in scaling is > >indicated > > Right. I think the only thing we might disagree on is the usefulness > of "reflectors". I think it's worth following that path for a while. > I don't have clear enough vision yet to agree with those who think they > are a wart on the nose of progress, etc. -- although they might be. I think my point is that there can be a tendency of people to setup a single reflector and then ask the world to connect to it. This is a bad idea. You need a chain of reflectors so that the users can connect to their nearest one. However, the more reflectors you put in the more closely you come to creating another MBONE structure. As Jon said at some point of scaling your distribution of this stuff multicast is the way to go, though, the reflector idea is maybe better for local distribution. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From rem-conf-request@es.net Wed Dec 14 12:16:03 1994 Received: from parmesan.cs.wisc.edu by osi-west.es.net via ESnet SMTP service id <03653-0@osi-west.es.net>; Wed, 14 Dec 1994 09:14:48 +0000 Date: Wed, 14 Dec 94 11:14:39 -0600 From: bob@cs.wisc.edu (Bob Kummerfeld) Message-Id: <9412141714.AA17701@parmesan.cs.wisc.edu> Received: by parmesan.cs.wisc.edu; Wed, 14 Dec 94 11:14:39 -0600 To: rem-conf@es.net Subject: Re: WXYC and MBONE, etc. - CuSeeme FAQ? Cc: pjones@mento.oit.unc.edu Is there a web site with more details on the reflector system and CuSeeme in general? Bob From rem-conf-request@es.net Wed Dec 14 13:19:10 1994 Received: from mento.oit.unc.edu by osi-west.es.net via ESnet SMTP service id <04516-0@osi-west.es.net>; Wed, 14 Dec 1994 10:18:16 +0000 Received: by mento.oit.unc.edu (NeXT-1.0 (From Sendmail 5.52)/TAS/11-16-88) id AA25874; Wed, 14 Dec 94 13:18:02 EST Date: Wed, 14 Dec 1994 13:18:01 -0500 (EST) From: Paul Jones To: Bob Kummerfeld Cc: rem-conf@es.net Subject: Re: WXYC and MBONE, etc. - CuSeeme FAQ? In-Reply-To: <9412141714.AA17701@parmesan.cs.wisc.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I hope that we've made the appropriate links on http://sunsite.unc.edu/wxyc/ If note holler at us and we'll do our best to improve the links. Also is rem-conf a listserv or majordomo or what? looks like I could learn a lot by subscribing. Thanks. ============================================================================ Paul Jones Paul_Jones@unc.edu voice:(919) 962-6501 fax:(919) 962-5664 Office FOR Information Technology School of Journalism and Mass Communication School of Information and Library Science University of North Carolina My other office has a window From REM-CONF-request@es.net Wed Dec 14 14:21:20 1994 Received: from pppl.gov by osi-west.es.net via ESnet SMTP service id <05120-0@osi-west.es.net>; Wed, 14 Dec 1994 11:20:48 +0000 Received: from RAX (rax.pppl.gov [192.55.106.12]) by pppl.gov (8.6.8.1/8.6.5) with SMTP id OAA07152 for ; Wed, 14 Dec 1994 14:20:44 -0500 From: schechtm@rax.pppl.gov Date: Wed, 14 Dec 1994 14:20:14 -0500 Message-Id: <94121414201397@rax.pppl.gov> To: REM-CONF@es.net Subject: subscribe X-VMS-To: REM-CONF@ES.NET X-VMS-Cc: SCHECHTM Plese add me to the rem-conf list. Thanks, Nathan Schechtman email: nschechtman@pppl.gov Princeton Plasma Physics Lab phone: 609-243-3465 Princeton, NJ 08543 From rem-conf-request@es.net Wed Dec 14 18:04:29 1994 Received: from N3.SP.CS.CMU.EDU by osi-west.es.net via ESnet SMTP service id <07815-0@osi-west.es.net>; Wed, 14 Dec 1994 15:04:04 +0000 Date: Wed, 14 Dec 94 18:03:03 EST From: Hui.Zhang@N3.SP.CS.CMU.EDU To: rem-conf@ES.NET Subject: CFP: ACM MULTIMEDIA'95 ACM MULTIMEDIA'95 November 5-9, 1995 Hyatt Regency (Embarcadero) San Francisco, CA THE THIRD ACM INTERNATIONAL MULTIMEDIA CONFERENCE AND EXHIBITION Sponsored by the ACM SIG Multimedia, SIGCHI, SIGGRAPH, SIGBIT, SIGOIS, SIGIR, and IEEE Communications Society PRELIMINARY CALL FOR PARTICIPATION Multimedia can substantially improve communication between information providers and consumers by making it more effective and more engaging. ACM Multimedia'95 will provide an international forum for papers, panels, videos, demonstrations, courses, workshops, and exhibits focusing on all aspects of this multi-disciplinary field: from underlying technologies to applications and issues, and from theory to practice. We invite your participation. Topics include, but are not limited to: applications in education, entertainment, government, medicine, etc.; collaboration environments; databases; digital libraries; distributed systems; documents and authoring; hardware and architectures; image, video and audio compression techniques; information retrieval; interactive television; media integration and synchronization; networking and communication; operating system extensions; programming paradigms and environments; standards and legal issues; storage and I/O architectures; tools; user interfaces; and virtual reality. Papers ------ Technical papers on completed or in-progress research, innovative applications, or experience with multimedia systems are solicited. Submissions must use a typeface no smaller than 10 point, double sided if possible, and be no longer than 12 pages including figures, tables, and references. Where applicable, prototype demonstrations or videotape presentations are encouraged to supplement the talks. Submit complete papers to: Polle Zellweger, Program Chair. Outstanding papers on different areas of multimedia will be given awards. Papers with a student as the primary author will enter a student paper award competition. A cover letter must identify the paper as a candidate for the student paper competition. Selected papers will be forwarded to ACM/Springer-Verlag Multimedia Systems, Communications of the ACM, IEEE/ACM Transactions on Networking, or ACM Transactions on Information Systems. Panels ------ Panels are solicited that examine innovative, controversial, or otherwise provocative issues of interest. Proposals should be limited to 2 pages, plus a biography of at most one paragraph for each participant. Submit panel proposals to: Fillia Makedon, Panels Chair. Videos ------ Videos of innovative multimedia technology should be 5-8 minutes long, in NTSC format, and accompanied by one copy of a 1-2 page description of the material shown in the video. Submit videos to: Gil Cruz, Videos Chair. Demonstrations -------------- We solicit demonstrations of working systems in technical and artistic categories. Submissions (at most 2 pages) should include a description of the exhibit, demo requirements, a biography, and a single VHS NTSC video. Submit demonstrations to: Tom Little, Demonstrations Chair. Courses ------- There will be a series of 1/2-day tutorial courses, focused on issues relevant to researchers and/or practitioners of multimedia technology. Proposals (at most 5 pages) should include a description of the subject matter and brief biographical sketches of the instructors. Evaluation of proposals will be based on expertise and experience of instructors, relevance of subject matter, and the use of multimedia technology in the presentation. Submit tutorial proposals to: Sorel Reisman, Tutorials Chair. Workshops --------- Workshops preceding the conference will allow participants to exchange ideas on a topic. Workshop results and issues will be integrated into the main body of the conference. Submit workshop proposals to: Ephraim Glinert, Workshops Chair. Exhibits -------- ACM Multimedia'95 offers a unique opportunity for vendors and publishers to exhibit and demonstrate multimedia products. For more information, contact Don Collier, Exhibition Manager. ============= Authors of accepted submissions will be required to submit both a camera- ready copy of the manuscript for the printed proceedings and an electronic copy for the CD ROM proceedings. Authors must assign copyright to ACM as a condition of publishing their work in the proceedings. An author who embeds an object, such as an art image, copyrighted by a third party is expected to obtain that party's permission to include the object with the understanding that the entire work may be distributed as a unity to ACM members and others. Up-to-date information about ACM Multimedia'95, including a more detailed version of this call, can be found on the World Wide Web at http://acm.org/MM95/. IMPORTANT DATES --------------- Six copies of all submissions due: March 29, 1995. Notification of acceptance: June 30, 1995. Submissions in final form due: August 11, 1995. CONFERENCE COMMITTEE -------------------- General Chair: Treasurer: R.B. Allen, Bellcore M. Brown, DEC Electronic Information: Networking: H. Zhang, CMU G. Paxinos, Metro Link Electronic Publishing: Proceedings: R. Phillips, LANL S. Heller, GWU Publicity: European Liaison: R. Mehrotra, UM-St. Louis C. Thanos, Consiglio Nazionale delle Ricerche (Pisa) Steering Committee Co-Chairs: S. Bulick, US WEST A. Kuchinsky, Hewlett Packard PROGRAM CHAIR: PANELS CHAIR: Polle Zellweger Fillia Makedon Xerox PARC Dept. of Math and Computer Sci. 3333 Coyote Hill Road Dartmouth College Palo Alto, CA 94304 USA 6211 Sudikoff Laboratory, Room 109 mm95@parc.xerox.com Hanover, NH 03755-3510 USA Phone: +1-415-812-4426 makedon@kinsman.dartmouth.edu Phone: +1-603-646-3048 VIDEOS CHAIR: DEMONSTRATIONS CHAIR: Gil Cruz, R. Hill Tom Little MRE-2B280 Dept. of Elec. and Computer Engr. Bellcore Boston University 445 South Street 44 Cummington St. Morristown, NJ 07960 USA Boston, MA 02215 USA {gil,rdh}@bellcore.com tdcl@spiderman.bu.edu Phone: +1-201-829-5212 Phone: +1-617-353-9877 TUTORIALS CHAIR: WORKSHOPS CHAIR: Sorel Reisman Ephraim Glinert Dept. of Computer Science Dept. of Computer Science California State University R. P. I. Fullerton, CA 92634 USA Troy, NY 12180 USA sreisman@ccvax.fullerton.edu glinert@cs.rpi.edu Phone: +1-714-773-3325 Phone: +1-518-276-2657 EXHIBITS CHAIR: EXHIBITOR INFORMATION: Brent Hailpern Don Collier IBM T.J. Watson Res. Ctr. DC Expositions, Inc. 30 Sawmill River Roada 555 Republic Drive, Suite #316 Hawthorne, NY 10532 USA Plano, TX 75074 USA bth@watson.ibm.com dcexpo@aol.com Phone: +1-914-784-6821 Phone +1-214-423-4286 1995 ACM INTERNATIONAL MULTIMEDIA CONFERENCE AND EXHIBITION From rem-conf-request@es.net Wed Dec 14 20:37:46 1994 Received: from Sun.COM by osi-west.es.net via ESnet SMTP service id <09212-0@osi-west.es.net>; Wed, 14 Dec 1994 17:37:08 +0000 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA12010; Wed, 14 Dec 94 17:37:05 PST Received: from montagne.Eng.Sun.COM by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA29550; Wed, 14 Dec 94 11:16:34 PST Received: by montagne.Eng.Sun.COM (5.0/SMI-SVR4) id AA19690; Wed, 14 Dec 1994 11:15:31 +0800 Date: Wed, 14 Dec 1994 11:15:31 +0800 From: Brent.Browning@Eng.Sun.COM (Brent Browning) Message-Id: <9412141915.AA19690@montagne.Eng.Sun.COM> To: rem-conf@es.net Subject: SunVideo DMA support X-Sun-Charset: US-ASCII Content-Length: 2580 Since several people have had this question recently I am forwarding the marketing response on SunVideo and DMA. ----- Begin Included Message ----- From: jonh@alphaleo (Jon Haass) Date: Tue, 13 Dec 1994 12:36:11 +0800 To: ijj@informatics.rutherford.ac.uk Subject: SunVideo DMA support > The implication seems to be, as Toerless and Mit were suggesting, that only > later SunVideo cards support DMA. If so, one would assume that this gives > (in a Solaris 2.4 system) a performance advantage over older cards without > DMA, and is thus a Good Thing... How can we tell in advance (e.g. before buying) if a SunVideo card supports DMA? Regarding your question on SunVideo and DMA: SunVideo 1.1 (so called to distinguish from 1.0 and 1.05!) began shipping in August of 1994. There should be no old stock of SunVideo that do not support DMA in the pipeline. Since some uses of the card do not care about DMA (e.g. if you are using Cell based compression) since the bit rate and CPU overhead are minimal, some customers would not care about these changes. Some customers DO care a lot. DMA capable boards have a rev-3 jalapeno chip. I can not give a serial number, unfortunately, that you can check for. It is also distinguished by a revision number on the back label -06 Rev 5.0. earlier boards are -03, -04 and -05. Solaris 2.3 Hardware Edition 8/94 does already support the DMA capability. So for direct capture (e.g. uncompressed) you no longer see the bottleneck of PIO at around 19 Mbits/sec. You can get up to 52 Mbits/sec allowing 24 bit, 30 fps 320 by 240 direct video. Solaris 2.4 just announced also supports DMA as well as new functionality through XIL in rtvc package libraries not available in 2.3. e.g. MPEG IPB with choice of IBP "molecules" YUYV 16 bit/pixel capture greyscale capture MPEG IPB transcode software in addition to general performance tuning. I hope this helps clarify the situation. You can expect no new performance improvements on hardware, but can expect new firmware over time to support other codecs or modes of operation. We did the YUYV particularly for supporting NV (Xerox PARC), so if you have a feature need, let us know, maybe we can help! Jon C. Haass jon.haass@Eng.Sun.COM Multimedia Products Manager (415) 336-3877 Product Marketing (415) 336-6042 (fax) ----- End Included Message ----- Brent Browning Software Engineer/Network Digital Media Sun Microsystems Computer Company Internet: brentb@Eng.Sun.COM 2550 Garcia Ave. MTV 02-208 http://www.sun.com/ Mountain View, CA 94043-1100 Phone: (415) 336-5573 From rem-conf-request@es.net Wed Dec 14 22:15:48 1994 Received: from pine.iecs.fcu.edu.tw by osi-west.es.net via ESnet SMTP service id <09975-0@osi-west.es.net>; Wed, 14 Dec 1994 19:15:12 +0000 Received: by pine.iecs.fcu.edu.tw.IECS.FCU.edu.tw (4.1/SMI-4.1) id AA19387; Thu, 15 Dec 94 11:05:07 CST Date: Thu, 15 Dec 94 11:05:07 CST From: srtsai@pine.IECS.FCU.edu.tw (Shwu-Rong Tsai) Message-Id: <9412150305.AA19387@pine.iecs.fcu.edu.tw.IECS.FCU.edu.tw> To: rem-conf@es.net Subject: unsubscribe unsubscribe From rem-conf-request@es.net Thu Dec 15 00:12:21 1994 Received: from wizard.gsfc.nasa.gov by osi-west.es.net via ESnet SMTP service id <10682-0@osi-west.es.net>; Wed, 14 Dec 1994 21:11:47 +0000 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA22908; Thu, 15 Dec 94 00:11:44 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9412150511.AA22908@wizard.gsfc.nasa.gov> Subject: Modified VIC.SD.TCL to Allow nv and vic to Peacefully Coexist To: rem-conf@es.net Date: Thu, 15 Dec 1994 00:11:43 -0500 (EST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6001 I recently created and am including a modified VIC.SD.TCL that allows nv and vic to peacefully coexist. In all cases below, vic will be invoked (in native vic mode) if vic video format is explicitly specified in sd. In its default state as supplied, nv will be invoked if the video format in sd is either nv or unspecified. This provides compatible behavior with past practice while also allowing simultaneous use of nv and vic. If you change the default_videofmt tcl variable to vic from nv, then nv will only be invoked when nv video format is explicitly specified in sd. If no video format is explicitly specified, then vic will be invoked in nv compatibility mode (option "-A nv"). This is useful if you want to use vic as your normal user interface for video conferences, but want to retain the ability to simultaneously use nv (by explicitly specifying nv format in sd). If you change the force_vic tcl variable from 0 to 1, then vic will be invoked even if nv (or ivs) format is explicitly specified in sd (in nv (or ivs) compatibility mode of course). This can be used when you want to guarantee using vic as your user interface, and you are not interested in running nv (or ivs) in parallel with vic. If you change the default_videotype tcl variable to vic from nv, then an assumption is made that the default video format being used for transmitting, when no video format is explicitly specified in sd, is being changed from nv to vic. This should probably not be changed unless a consensus decision is reached on the MBone to change to a new default behavior, or for strictly private use. If not set properly, it could result in an incompatible video format being used on those video conferences that don't explicitly specify a video format in sd (which is not an uncommon occurrence), with the result that the conference could not be viewed. All the normal caveats apply. Also, I did not test this with ivs (although it should be equivalent to nv), nor did I test the vat/vic automagic video switching interaction (although I did check ps and it appeared the proper arguments were being passed to vat and vic in all cases). I just had a need for this (simultaneous use of nv and vic) and I thought it might also be of use to others. -Bill P.S. I also didn't change any of the comment lines in the VIC.SD.TCL file. Modified VIC.SD.TCL: ------------------------------------------------------------------------ # This is a version of ~/.sd.tcl modified to support vic video. # There are two sets of changes: # # - vic is used (in nv/ivs compatability mode) instead of nv, ivs # or telesia. vic is also used, of course, in its `native' rtp v2 # mode for sessions of type "vic". # # - the audio startup is modified to establish a 'session bus' between # vat & vic for sessions where both audio & video are specified. # this allows the 'voice switched' window mode in vic to work. # # -- Van Jacobson & Steve McCanne # Tue Nov 29 06:11:41 PST 1994 # # $Header: VIC.SD.TCL,v 1.6 94/12/05 00:29:05 mccanne Exp $ set ipc_chan 0 proc get_channel { confid } { global ipc_tab ipc_chan if { [info exists ipc_tab($confid)] } { return $ipc_tab($confid) } incr ipc_chan if { $ipc_chan > 300 } { set ipc_chan 1 } set ipc_tab($confid) $ipc_chan return $ipc_chan } proc start_audio {} { global sd_sess sd_audio sd_video default_videofmt force_vic set audiofmt "" set packetfmt "-n" set mode "-c" foreach a $sd_audio(attributes) { case $a { fmt:* { set audiofmt [string range $a 4 end] } vt { set packetfmt "-v" } lecture { set mode "-l" } } } set confaddr [format "%s/%s/%s/%s/%s" $sd_sess(address) \ $sd_audio(port) $sd_audio(conf_id) $audiofmt $sd_sess(ttl)] global vat if {(([lsearch $sd_sess(media) video] >= 0) && \ (($force_vic == 1) || \ ([lsearch $sd_video(attributes) fmt:vic] >= 0) || \ (([lsearch $sd_video(attributes) fmt:*] < 0) && \ ($default_videofmt == "vic"))))} { set chan [get_channel $sd_sess(address)/$sd_video(port)] exec $vat -I $chan -C $sd_sess(name) $packetfmt $mode $confaddr & } else { exec $vat -C $sd_sess(name) $packetfmt $mode $confaddr & } } proc start_video {} { global sd_sess sd_video default_videofmt default_videotype force_vic set videofmt $default_videofmt set videotype $default_videotype foreach a $sd_video(attributes) { case $a { fmt:* { set videofmt [string range $a 4 end] set videotype $videofmt } } } case $videofmt { vic { } ivs { } nv { if { $force_vic == 0 } { global nv exec $nv -ttl $sd_sess(ttl) $sd_sess(address) \ $sd_video(port) & return } } telesia { set videofmt ivs } ivs { if { $force_vic == 0 } { global ivs exec nice $ivs -a -r -T $sd_sess(ttl) \ $sd_sess(address)/$sd_video(port) & return } } jpg { global imm exec nice $imm -p $sd_video(port) -I $sd_sess(address) \ -ttl $sd_sess(ttl) -n $sd_sess(name) & return } default { puts "sd: unknown video format: $videofmt" return } } global vic if {[lsearch $sd_sess(media) audio] >= 0} { set chan [get_channel $sd_sess(address)/$sd_video(port)] exec nice $vic -I $chan -A $videotype -t $sd_sess(ttl) \ -C $sd_sess(name) \ $sd_sess(address)/$sd_video(port) & } else { exec nice $vic -A $videotype -t $sd_sess(ttl) \ -C $sd_sess(name) \ $sd_sess(address)/$sd_video(port) & } } set sd_menu(video) "fmt: vic nv ivs jpg" set vic vic set default_videofmt nv set default_videotype nv set force_vic 0 From rem-conf-request@es.net Thu Dec 15 03:27:30 1994 Received: from vm.biu.ac.il by osi-west.es.net via ESnet SMTP service id <12279-0@osi-west.es.net>; Thu, 15 Dec 1994 00:26:59 +0000 Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2) with BSMTP id 5370; Thu, 15 Dec 94 10:26:18 IST Received: from VM.BIU.AC.IL (NJE origin HANK@BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 8290; Thu, 15 Dec 1994 10:26:18 +0200 Date: Thu, 15 Dec 94 10:20:05 IST From: Hank Nussbacher Subject: Video in Boston To: rem-conf@es.net Reply-To: Hank Nussbacher MIME-Version: 1.0 Content-Type: Text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Sorry to bother this list but I have been asked to find out if the following is possible. For a conference here in Israel next month the editor of Computerworld has agreed to give a video interview in Boston. Computerworld, the reporter and the conference all want to use the Internet to send the video to Israel for viewing. This will not be a live broadcast but rather a taped broadcast. The conference organizers want to know if there is anyone in the Boston area who can take a standard video tape, convert it to MPEG or Quicktime (or any other up and coming popular Internet standard) and place the file on an anonymous FTP server where we can retrieve it. The conference will cover any expenses incurred. Please contact me directly at hank@vm.tau.ac.il and not via the list. I need an answer by Dec 23th. Thanks, Hank Nussbacher Israel From rem-conf-request@es.net Thu Dec 15 10:20:39 1994 Received: from trout.nosc.mil by osi-west.es.net via ESnet SMTP service id <15160-0@osi-west.es.net>; Thu, 15 Dec 1994 07:20:11 +0000 Received: from cod (cod.nosc.mil) by trout.nosc.mil (4.1/SMI-4.1) id AA14244; Thu, 15 Dec 94 07:20:09 PST Received: from othomas-PC (ppc-17.nosc.mil) by cod (4.1/SMI-4.1) id AA08879; Thu, 15 Dec 94 07:18:53 PST Date: Thu, 15 Dec 94 07:18:52 PST From: othomas@nosc.mil (Owen F. Thomas) Message-Id: <9412151518.AA08879@cod> To: rem-conf@es.net Subject: unsubscribe unsubscribe From rem-conf-request@es.net Thu Dec 15 16:22:09 1994 Received: from ezmail.ucs.indiana.edu by osi-west.es.net via ESnet SMTP service id <18862-0@osi-west.es.net>; Thu, 15 Dec 1994 13:21:44 +0000 Received: by ezmail.ucs.indiana.edu id AA24846 (5.67b/IDA-1.5 for rem-conf@es.net); Thu, 15 Dec 1994 16:21:30 -0500 Date: Thu, 15 Dec 1994 16:21:29 -0400 (CDT) From: Allen Robel Sender: Allen Robel Reply-To: Allen Robel Subject: Layperson's experience upgrading to 3.3 from 2.x, SunOS 4.1.3_U1 To: rem-conf@es.net Cc: robelr@indiana.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII I just upgraded our mrouter to 3.3 and thought I'd pass along my experiences since the upgrade wasn't completely painless (are they ever?). Wizards can definitely skip this, but maybe it'll be of help to other laypeople... I picked up the 3.3 distribution from: parcftp.xerox.com:pub/net-research/ipmulti3.3-sunos413x.tar.Z And Jim Culbert's mcast_install script from: iesl.mit.edu:pub/mcast/mcast_install and ran this script from the root of the 3.3 source tree, answered all the questions it asks, and received two error messages at the end of the process (during ld's work). Both had to do with undefined symbols, the first of which I can't remember and the second symbol being _Random. To fix the first, I manually copied all of: ip_mrout* ip_mrout* igmp* >from the distribution (for me, that's /usr/local/src/release3.3/sys.sunos413_U1/netinet/) to the /usr/sys/netinet directory. To fix the undefined _Random thing, I manually edited the Makefile that the script creates (when it calls /etc/config): /usr/sys/sun4c//Makefile I added to the section: OBJS= the following: ../OBJ/igmp_random.o (I put it after ../OBJ/igmp.o but I think it could go anywhere in this section). Seems the mcast_install script doesn't seem to do whatever magic is needed to add this. After adding that, I typed "make" in the /usr/sys/sun4c// directory and things went OK. So, one more site is at 3.3... (although we're getting our MBONE feed >from a 2.0 machine at the moment :-( regards, +--------------------------------------------------------------------+ | Allen Robel | http://cell-relay.indiana.edu/allen/home.html | | robelr@indiana.edu | "a page with no excuse..." | +--------------------------------------------------------------------+ From rem-conf-request@es.net Thu Dec 15 17:30:57 1994 Received: from rpi.edu by osi-west.es.net via ESnet SMTP service id <19803-0@osi-west.es.net>; Thu, 15 Dec 1994 14:30:27 +0000 Received: from hibp.ecse.rpi.edu (hibp7.ecse.rpi.edu) by rpi.edu (4.1/SMHUB41); id AA06176; Thu, 15 Dec 94 17:30:23 EST for rem-conf@es.net Received: from hibp6.ecse.rpi.edu by hibp.ecse.rpi.edu (4.1/ST26); id AA27560 for rem-conf@es.net; Thu, 15 Dec 94 17:30:23 EST Message-Id: <9412152230.AA27560@hibp.ecse.rpi.edu> To: rem-conf@es.net Subject: MSessmon X-Mailer: exmh version 1.4zeta 6/3/94 Date: Thu, 15 Dec 1994 17:30:21 -0500 From: Paul Stewart During the course of the summer and this class semester, I've been involved in writing an RTPv2 based session monitor. Thanks to all of the help and comments I've had over the course of my development, I've been able to complete what I hope to be a first working prototype. I'd like to test it out using the MBone and whoever is interested on generating reports. Ideally, I'd like a number of people capable of sending and receiving RTPv2 streams (currently I've been using vat). MSessmon, my session monitor, works completely on receipt of RTCP packets. It starts by displaying a list of currently sending SSRCs, and allows graphical representation of the reciever map for each of these. The reciever map is an abbreviated graph of the MBone topology, which only shows "significant" vertices along the path to the receivers. It offers a color-coded display which shows reception quality (loss percentage) and length of time since last report. It is also possible to get a stripchart displayed for any number of displayed nodes. The graph display has a few different algorithms, none of which I'm quite happy with yet, but perhaps I'll refine one of them to my liking eventually. Anyway that's the short of it. I'd like to arrange to set up a session in sd where I'll have lots of input so I can work out some of the applications' quirks and get some data. Is anyone interested? Send me email (stewart@rpi.edu) and I'll give you a pointer to the (_really_ prerelease) application, in return for your commitment to be around in the next couple of days so we can test it out. :-) So, who can play tomorrow? More documentation will become available in time, but I'm very time-constrained as of late. -- Paul From rem-conf-request@es.net Fri Dec 16 05:52:15 1994 Received: from cismsun.univ-lyon1.fr by osi-west.es.net via ESnet SMTP service id <26559-0@osi-west.es.net>; Fri, 16 Dec 1994 02:51:32 +0000 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.9/8.6.6) id LAA26858 for rem-conf@es.net; Fri, 16 Dec 1994 11:51:21 +0100 Message-Id: <199412161051.LAA26858@cismsun.univ-lyon1.fr> Subject: xil lib & vic To: rem-conf@es.net Date: Fri, 16 Dec 1994 11:51:19 +0100 (MET) From: Lucia Gradinariu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 314 Sorry, I've posted a wrong answer. In fact there is no xil_device_create function in XIL. There is only xil_create_from_device. Is that what it should be used in vic.xil sources with Solaris 2.3/XIL 1.1/SunVideo1.0? I have only used xil.rtvc and I had no problems (for the moment) Lucia.Gradinariu@univ-lyon1.fr From rem-conf-request@es.net Fri Dec 16 06:20:51 1994 Received: from cancer.ucs.ed.ac.uk by osi-west.es.net via ESnet SMTP service id <26797-0@osi-west.es.net>; Fri, 16 Dec 1994 03:20:26 +0000 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.9/8.6.9) with ESMTP id LAA04906; Fri, 16 Dec 1994 11:18:58 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id LAA12286; Fri, 16 Dec 1994 11:18:56 GMT Date: Fri, 16 Dec 1994 11:18:55 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Lucia Gradinariu cc: rem-conf@es.net Subject: Re: xil lib & vic In-Reply-To: <199412161051.LAA26858@cismsun.univ-lyon1.fr> Message-ID: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-URL: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 16 Dec 1994, Lucia Gradinariu wrote: > Sorry, I've posted a wrong answer. In fact there is no xil_device_create > function in XIL. There is only xil_create_from_device. Is that what it > should be used in vic.xil sources with Solaris 2.3/XIL 1.1/SunVideo1.0? > I have only used xil.rtvc and I had no problems (for the moment) The problem is that vic is not supported in Solaris 2.3. It will work properly only with Solaris 2.4. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From rem-conf-request@es.net Fri Dec 16 09:07:20 1994 Received: from sangam.ncst.ernet.in by osi-west.es.net via ESnet SMTP service id <27804-0@osi-west.es.net>; Fri, 16 Dec 1994 06:06:43 +0000 Received: from iisc.ernet.in (iisc.iisc.ernet.in [144.16.64.3]) by sangam.ncst.ernet.in (8.6.8.1/8.6.6) with SMTP id TAA07920 for ; Fri, 16 Dec 1994 19:36:40 +0500 Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id AA26363; Fri, 16 Dec 94 19:40:58+0530 Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA19683; Fri, 16 Dec 94 19:40:49+0530 From: anand@ece.iisc.ernet.in (SVR Anand) Message-Id: <9412161410.AA19683@ece.iisc.ernet.in> Subject: Side Chat and RTP To: rem-conf@es.net Date: Fri, 16 Dec 94 19:40:49 GMT+5:30 X-Mailer: ELM [version 2.3 PL11] Hello After going through the document that discusses about the issues the were considered to develop transport protocol for realtime applications like audio/video the following aspect seems to be ignored for some reason. In any conference we always have the main speaker(s) and we can also expect considerable side chats that go on simultaneously. These side chats may be between one or more participants. So far as the network is concerned the load will likely be decided by these rather than the main one, since the side chats may be end to end in nature and is more like a dedicated channel. The main speeker's reach is more broader, hence multicasting can be made use of. (Unless one goes ahead and multicasts even these private conversations). When it comes to the bandwidth reservation and the scheduling strategies that are employed at the intermediate routers that understand RTP packets, shouldn't there be a provision in RTP that enables these intermediate routers to distinguish between these "different" kinds of traffic ? This may help in intelligently servicing these flows by giving different priorities as well as making bandwidth reservations within the network. For one thing, you may object this by saying that this is not the responsibility of RTP to take care of what network provides. But it may help. (A guess ofcourse). I might have been over enthuciastic than being rational. Just thought that I should spell out, more to clarify my own understanding. If these thoughts make some sense I will be glad to get responses from the experts like you. regards Anand. From rem-conf-request@es.net Fri Dec 16 10:42:54 1994 Received: from cismsun.univ-lyon1.fr by osi-west.es.net via ESnet SMTP service id <28476-0@osi-west.es.net>; Fri, 16 Dec 1994 07:42:18 +0000 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.9/8.6.6) id QAA05211; Fri, 16 Dec 1994 16:42:10 +0100 Message-Id: <199412161542.QAA05211@cismsun.univ-lyon1.fr> Subject: Re: xil lib & vic To: Graeme.Wood@ucs.ed.ac.uk Date: Fri, 16 Dec 1994 16:42:07 +0100 (MET) From: Lucia Gradinariu Cc: rem-conf@es.net In-Reply-To: from "Graeme Wood" at Dec 16, 94 02:35:56 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 938 > SMCC Solaris 2.4 is released and is shipping from about now. > Maintenance customers will not see it until end of next month. > > SunSoft Solaris 2.4 has been available since July/August. SMCC > customers have been able to join an early access program if they wished. > > ============================================================================= > Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk > Unix Systems Support Phone: +44 131 650 5003 > The University of Edinburgh Fax: +44 131 650 6552 > ----------------------------------------------------------------------------- > Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk > for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ > ============================================================================= > > Yes, he's right! lucia@univ-lyon1.fr From rem-conf-request@es.net Fri Dec 16 12:00:43 1994 Received: from scotch.com by osi-west.es.net via ESnet SMTP service id <29402-0@osi-west.es.net>; Fri, 16 Dec 1994 09:00:08 +0000 Received: (from uucp@localhost) by blacksun.metaverse.com (8.6.9/8.6.9) id IAA19072; Fri, 16 Dec 1994 08:56:05 -0800 Received: from mailhost(140.174.161.4) by blacksun via smap (V1.3mjr) id sma019064; Fri Dec 16 16:56:00 1994 Received: from beli by metaverse.com (5.x/SMI-SVR4) id AA19002; Fri, 16 Dec 1994 08:57:09 -0800 Date: Fri, 16 Dec 1994 08:35:34 -800 (PST) From: Karl Jacob Reply-To: kaj@metaverse.com Subject: Re: xil lib & vic To: lucia@univ-lyon1.fr, Graeme.Wood@ucs.ed.ac.uk Cc: rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is incorrect I used vic for a 12 hour broadcast last weekend on a Solaris 2.3 machine with the recommended patches installed. I had no problems on either the sending or receiving end. Karl > >The problem is that vic is not supported in Solaris 2.3. It will work >properly only with Solaris 2.4. > >============================================================================= >Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk >Unix Systems Support Phone: +44 131 650 5003 >The University of Edinburgh Fax: +44 131 650 6552 >----------------------------------------------------------------------------- >Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk >for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ >============================================================================= > From rem-conf-request@es.net Fri Dec 16 12:17:21 1994 Received: from cancer.ucs.ed.ac.uk by osi-west.es.net via ESnet SMTP service id <29563-0@osi-west.es.net>; Fri, 16 Dec 1994 09:15:09 +0000 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.9/8.6.9) with ESMTP id RAA09690; Fri, 16 Dec 1994 17:14:52 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id RAA13294; Fri, 16 Dec 1994 17:14:50 GMT Date: Fri, 16 Dec 1994 17:14:49 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Karl Jacob cc: lucia@univ-lyon1.fr, rem-conf@es.net Subject: Re: xil lib & vic In-Reply-To: Message-ID: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-URL: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 16 Dec 1994, Karl Jacob wrote: > This is incorrect I used vic for a 12 hour broadcast last weekend > on a Solaris 2.3 machine with the recommended patches installed. > I had no problems on either the sending or receiving end. I bet you were using the RTVC version rather then the XIL version. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From rem-conf-request@es.net Fri Dec 16 13:21:44 1994 Received: from scotch.com by osi-east.es.net via ESnet SMTP service id <20448-0@osi-east.es.net>; Fri, 16 Dec 1994 10:21:21 +0000 Received: (from uucp@localhost) by blacksun.metaverse.com (8.6.9/8.6.9) id KAA23774; Fri, 16 Dec 1994 10:12:20 -0800 Received: from mailhost(140.174.161.4) by blacksun via smap (V1.3mjr) id sma023755; Fri Dec 16 18:11:43 1994 Received: from beli by metaverse.com (5.x/SMI-SVR4) id AA23665; Fri, 16 Dec 1994 10:12:50 -0800 Date: Fri, 16 Dec 1994 09:51:16 -800 (PST) From: Karl Jacob Reply-To: kaj@metaverse.com Subject: Re: xil lib & vic To: kaj@neuromancer.metaverse.com, Graeme.Wood@ucs.ed.ac.uk Cc: lucia@univ-lyon1.fr, rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII You are correct, sorry for the misunderstanding. >On Fri, 16 Dec 1994, Karl Jacob wrote: > >> This is incorrect I used vic for a 12 hour broadcast last weekend >> on a Solaris 2.3 machine with the recommended patches installed. >> I had no problems on either the sending or receiving end. > >I bet you were using the RTVC version rather then the XIL version. > >============================================================================= >Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk >Unix Systems Support Phone: +44 131 650 5003 >The University of Edinburgh Fax: +44 131 650 6552 >----------------------------------------------------------------------------- >Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk >for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ >============================================================================= > Karl From rem-conf-request@es.net Fri Dec 16 14:17:26 1994 Received: from herman.cmf.nrl.navy.mil by osi-west.es.net via ESnet SMTP service id <00763-0@osi-west.es.net>; Fri, 16 Dec 1994 11:16:35 +0000 Received: from localhost (fenner@localhost) by herman.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id OAA03697; Fri, 16 Dec 1994 14:15:09 -0500 Message-Id: <199412161915.OAA03697@herman.cmf.nrl.navy.mil> X-Mailer: exmh version 1.5.1 12/2/94 To: Allen Robel cc: rem-conf@es.net Subject: Re: Layperson's experience upgrading to 3.3 from 2.x, SunOS 4.1.3_U1 In-reply-to: Your message of "Thu, 15 Dec 94 16:21:29 -0400." X-Face: -*.ZYbFWa}{2c8NmF| Sounds like you tried patching from a 2.x kernel tree, instead of a raw sunos tree. mcast_install probably complained bitterly, with lots of failed patches, but since its output is so verbose anyway, you probably didn't notice. You should also check and make sure that your multicast kernel config file has "options RSVP_ISI" in it. If it doesn't, then your kernel is built oddly and will probably send out its IGMP messages with very high TTL's, which is a bad thing. You will need to add that option, re-"config" the kernel, do a "make clean" and then a "make". Bill From rem-conf-request@es.net Fri Dec 16 16:34:57 1994 Received: from gw1.att.com by osi-west.es.net via ESnet SMTP service id <02300-0@osi-west.es.net>; Fri, 16 Dec 1994 13:34:14 +0000 Received: from arch4.ho.att.com by ig2.att.att.com id AA21845; Fri, 16 Dec 94 14:15:08 EST Received: from arch5.ho.att.com by arch4.ho.att.com (4.1/EMS-1.2 GIS) id AA09846; Fri, 16 Dec 94 14:04:39 EST Received: by arch5.ho.att.com (4.1/EMS-1.2 GIS) id AA13711; Fri, 16 Dec 94 14:04:37 EST Date: Fri, 16 Dec 94 14:04:37 EST Message-Id: <9412161904.AA13711@arch5.ho.att.com> From: cn2@arch4.ho.att.com To: vcl@arch4.ho.att.com, joel@arch4.ho.att.com, sig11@roses.stanford.edu, uist.chi@xerox.com, tf-mm@i4serv.informatik.rwth-aachen.de, ir-l%uccvma.bitnet@cunyvm.cuny.edu, s-comput@tcsvm.bitnet, smds@nri.reston.va.us, iplpdn@nri.reston.va.us, cip@bbn.com, icad-request@santafe.edu, sigmedia@bellcore.com, sound@acm.org, announcements.chi@Xerox.com, tcplw@cray.com, arl@arl1.wustl.edu, ccrc@dworkin.wustl.edu, g-troup@dworkin.wustl.edu, f-troup@dsl.cis.upenn.edu, end2end-interest@venera.isi.edu, atm@bbn.com, rem-conf@es.net, ietf@venera.isi.edu, tccc@cs.umass.edu Subject: Community Networking Call For Participation ============================================================================= Call for Participation ============================================================================= SECOND INTERNATIONAL WORKSHOP ON COMMUNITY NETWORKING INTEGRATED MULTIMEDIA SERVICES TO THE HOME June 20-22, 1995 Princeton, New Jersey, USA Sponsored by the IEEE Communications Society In collaboration with ACM SIGCOMM* Community networking concerns the network infrastructures that will bring integrated multimedia services to home users. Community networking differs in many ways from enterprise networking in its services, technologies, and economics. In contrast to enterprise networking applications, community networking services will not necessarily be work oriented and will range from entertainment to shopping to information services. At present, community networking technology is driven by the requirements of video-on-demand, most notably high bandwidth (compared to narrowband), bandwidth asymmetry, and the delay-jitter constraints imposed by today's limited-storage TV set-top devices. As various other services develop, community networking will evolve to include integrated multimedia communication and user-to-user applications. Community networking must also provide access to resources located outside the community, in an increasingly global repository of information of every conceivable type. This workshop will give researchers and professionals the chance to share their views and advance the state of the art in this field. RELEVANT AREAS: Contributions are encouraged in the five areas listed below with relevant topics: 1. APPLICATIONS AND REQUIREMENTS: types of applications; coding; set-top operating systems; QoS networking requirements (symmetric/asymmetric bandwidth, delay, and losses); security and privacy; service models; user interface and navigation facilities. 2. LOCAL DISTRIBUTION TECHNOLOGY: topology; fiber/cable/UTP/wireless; modulation, bandwidth allocation; MAC (reverse channel); role of ATM; dependencies on equipment/network in the home (e.g., TV set-top). 3. ADDRESSING, SIGNALING, AND UPPER-LAYER PROTOCOLS: local vs. global addressing; the service provider view vs. the common carrier view: the video-dialtone gateway; role of B-ISDN protocols; network- and transport-layer protocols; network management; APIs. 4. INTERNETWORKING AND ARCHITECTURE: the gateway: accessing other networks (data, telephone); server placement and network optimization; the regional distribution centers; testbeds; network traffic models; network cost structure and its implications on service pricing; medium- and long-term network evolution; the impact of regulatory constraints. 5. COMMUNITY ASPECTS, OPPORTUNITIES FOR GROWTH: the success of community networking depends of the degree to which it meets community needs and invites the full participation of community members; community needs, desires and aspirations; networking approaches that have worked well in the past and others that have not; obstacles to success that need to be overcome. INSTRUCTIONS FOR SUBMITTING ABSTRACTS: Please send via electronic mail a detailed abstract (up to 3 pages in ASCII or PostScript) describing a position statement in one of the areas above to cn2@arch4.ho.att.com Note that submissions longer than the limit above will not be reviewed. Only if electronic submission is impossible, a hardcopy version may be sent to: Joel Winthrop AT&T Bell Laboratories 101 Crawfords Corner Rd., RM 1K-306 Holmdel, NJ 07733, USA Participation in the workshop will be by invitation only based on the Program Committee's review of position statements. Some of the authors will be asked to submit papers and to present them during the workshop. Workshop size limitation may preclude attendance of all authors of multi-author abstracts. DATES: Deadline for submitting abstracts . . . . . . . . March 17, 1995 Acceptance notification . . . . . . . . . . . . . April 17, 1995 Papers due (limited to 8 pages) . . May 19, 1995 PROGRAM COMMITTEE: Program Chair: Joel Winthrop AT&T Bell Labs, Holmdel, New Jersey Publication Chair: Vince Lesch AT&T Bell Labs, Holmdel, New Jersey Committee Members: Joydeep Bose National Computer Board, Singapore Jurgen Brommelhoff Digital Equipment Corporation G. Keith Cambron Pacific Bell Andrew Davidson Phillips Interactive Media of America Jeff H. Derby IBM Corporation Alexander D. Gelman Bellcore Riccardo Gusella Hewlett-Packard Laboratories, Palo Alto, California Gordon Kerr BT Labs Andrew Laursen Oracle Corporation Andrew Lippman MIT, Media Lab Tetsuya Miki NTT Transmission Systems Laboratories Mario Morino Morino Foundation Martin De Prycker Alcatel Bell Telephone, Antwerp, Belgium David Skellern Macquarie University, Sydney Albert J. Stienstra Philips Research Mario P. Vecchi Time Warner Cable, Inc. William E. Wall Scientific-Atlanta, Inc. * Approval Pending From rem-conf-request@es.net Fri Dec 16 17:30:57 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <02789-0@osi-west.es.net>; Fri, 16 Dec 1994 14:30:17 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Fri, 16 Dec 1994 14:30:02 -0800 Posted-Date: Fri 16 Dec 94 14:28:51 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Fri, 16 Dec 94 14:28:52 PST Date: Fri 16 Dec 94 14:28:51 PST From: Stephen Casner Subject: Re: Side Chat and RTP To: anand@ece.iisc.ernet.in, rem-conf@es.net Message-Id: <787616931.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9412161410.AA19683@ece.iisc.ernet.in> Mail-System-Version: Anand, RTP works fine for unicast communication in addition to multicast. Side chats might use unicast if they were only point-to-point, or they might use multicast if more than two parties might be involved. Routers will know how to forward the packets based on the unicast and multicast routing; reservations will be made following the same distribution paths. I don't think any additional mechanism is needed in RTP to help the network level, nor would it be appropriate. There is still a lot of discussion underway about how "flow IDs" will be assigned to packets, but I don't expect this to affect the RTP protocol itself. -- Steve ------- From rem-conf-request@es.net Fri Dec 16 21:41:18 1994 Received: from koriel.Sun.COM by osi-west.es.net via ESnet SMTP service id <05473-0@osi-west.es.net>; Fri, 16 Dec 1994 18:40:51 +0000 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA28543; Fri, 16 Dec 94 18:40:49 PST Received: from halei.eng.sun.com by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA04492; Fri, 16 Dec 94 18:41:53 PST Received: by halei.eng.sun.com (5.0/SMI-SVR4) id AA00724; Fri, 16 Dec 1994 18:42:07 +0800 Date: Fri, 16 Dec 1994 18:42:07 +0800 From: Gerard.Fernando@Eng.Sun.COM (Gerard Fernando) Message-Id: <9412170242.AA00724@halei.eng.sun.com> To: rem-conf@es.net Subject: MPEG4 compression standard X-Sun-Charset: US-ASCII Content-Length: 2001 Here's the Call for Proposals for MPEG4. The "Proposal Package Description" is in: ftp://playground.sun.com/pub/mpeg/mpeg4ppd.ps Regards Gerard Fernando Sun ====================================================================== INTERNATIONAL ORGANISATION FOR STANDARDISATION ORGANISATION INTERNATIONALE NORMALISATION ISO/IEC JTC1/SC29/WG11 CODING OF MOVING PICTURES AND ASSOCIATED AUDIO ISO/IEC JTC1/SC29/WG11 N0820 MPEG 94/ November 1994 Title: MPEG-4 Call for Proposals Source:AOE Group Status:Approved at 29th WG11 meeting MPEG, a working group in ISO/IEC has produced two important standards (MPEG-1 and MPEG-2), and has started work on the MPEG-4 standard with completion scheduled in 1998. The development foresees a number of phases, one of which is a request to interested parties for proposals of partial or complete solutions meeting certain objectives. These are described in the Proposal Package Description (PPD) which forms an Annex to this document. This document describes current thinking on this matter. It is widely distributed to give notice that interested parties must respond by 1 October 1995, and to solicit comments on the goals and methods of attaining them. It is anticipated the current PPD document will be revised in March and July 1995 taking into account comments received and ongoing evolution of thinking in the working group. Interested people are asked to respond. Further information can be obtained from: Cliff Reader, Ph.D., Chairman AOE Group Samsung Semiconductor, Inc 3655 North First Street; San Jose, CA 95134 USA Tel.: +1 408 954 7853 Fax: +1 408 954 7150 Email: cliff@reader.com Leonardo Chiariglione, Ph.D., Convenor WG11 CSELT - Centro Studi e Laboratori Telecomunicazioni S.p A. Via G.Reiss Romoli, 274; 10148 Torino (Italy) Tel.: +39 11 228 6120 Fax: +39 11 228 6299 Email: leonardo.chiariglione@cselt.stet.it ====================================================================== END From rem-conf-request@es.net Sat Dec 17 11:51:06 1994 Received: from trystero.radio.com by osi-west.es.net via ESnet SMTP service id <11501-0@osi-west.es.net>; Sat, 17 Dec 1994 08:50:07 +0000 Received: (carl@localhost) by trystero.radio.com (8.6.9/940816.06ccg) id LAA23716; Sat, 17 Dec 1994 11:50:05 -0500 From: Carl Malamud Message-Id: <199412171650.LAA23716@trystero.radio.com> Subject: Karaoke Multicast of Handel's Messiah To: rem-conf@es.net Date: Sat, 17 Dec 1994 11:50:05 -0500 (EST) Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1534 I'm writing for two purposes: First, there is no truth to the rumor that sending mailbombs to santa@north.pole.org will generate money for charity. Check out http://north.pole.org/ for the real story, but Santa has enough messages to keep him and the Elves busy for quite a while. Further mailbombs may result in administrative actions such as Santa putting your name on the "naughty" list. You better watch out, etc., etc. (Those of you who have had to administer sendmail can guess the sinking feeling our poor elfmasters had when we typed "mailq" and received the information that there were 42,150 unprocessed messages in the queue-- and that was *before* the real deluge started.) Second, with the raging success of Internet-based charity campaigns under on our belt (;-) we're ready to add yet another feature to the North.Pole.Org holiday program. On Wednesday, Dec. 23 at 8:30PM Eastern time, the Internet Multicasting Service will present a live multicast of the annual Handel's Messiagh sing-along from the Kennedy Center for the Performing Arts. The multicast will use audio and whiteboard. The whiteboard will hold the lyrics and we will even provide a red bouncing ball. No gaurantee that wb and vat will synchronize, but we figure the opportunity to try a religious karaoke multicast is something that doesn't come along too often. All this is subject to our usual caveat on cheap stunts that what might go wrong probably will. Carl Malamud Associate Elfmaster, Dept. of Spam North.Pole.Org From rem-conf-request@es.net Sat Dec 17 19:15:31 1994 Received: from trystero.radio.com by osi-west.es.net via ESnet SMTP service id <13838-0@osi-west.es.net>; Sat, 17 Dec 1994 16:15:07 +0000 Received: (carl@localhost) by trystero.radio.com (8.6.9/940816.06ccg) id TAA25514 for rem-conf@es.net; Sat, 17 Dec 1994 19:15:06 -0500 From: Carl Malamud Message-Id: <199412180015.TAA25514@trystero.radio.com> Subject: Wednesday has been moved to Friday To: rem-conf@es.net Date: Sat, 17 Dec 1994 19:15:05 -0500 (EST) Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 304 As many of you know, the Internet Multicasting Service has always had a problem with the concept of time and date. As per the astute observations of many trained engineers, our original intent to broadcast on the first-ever religious karaoke multicast on Weds. Dec. 23 has been moved to Fri. Dec. 23. From rem-conf-request@es.net Mon Dec 19 12:22:45 1994 Received: from fnal.fnal.gov by osi-west.es.net via ESnet SMTP service id <27309-0@osi-west.es.net>; Mon, 19 Dec 1994 09:22:14 +0000 Return-receipt-to: Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HKTQR0J1JK00NYQO@FNAL.FNAL.GOV>; Mon, 19 Dec 1994 11:20:50 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA00565; Mon, 19 Dec 94 11:20:16 CST Date: Mon, 19 Dec 1994 11:20:15 -0600 From: Matt Crawford Subject: I do not want this Sender: crawdad@munin.fnal.gov To: towsley@gonzo.cs.umass.edu Cc: valerie@vax2.cs.umass.edu, rem-conf@es.net Message-id: <9412191720.AA00565@munin.fnal.gov> Content-transfer-encoding: 7BIT Don Towsley, I do not wish to see 400 kb/s of your office wall. I think your transmission is uselessly degrading the MBONE. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From rem-conf-request@es.net Mon Dec 19 13:47:00 1994 Received: from mailsun.aber.ac.uk by osi-west.es.net via ESnet SMTP service id <28391-0@osi-west.es.net>; Mon, 19 Dec 1994 10:46:37 +0000 Received: from mailhost.aber.ac.uk (actually saturn.dcs.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (PP); Mon, 19 Dec 1994 18:46:24 +0000 To: rem-conf@es.net cc: dap@aber.ac.uk, mdt@aber.ac.uk Subject: Sunjective Video Quality etc ? Date: Mon, 19 Dec 1994 18:46:18 +0000 Message-ID: <13624.787862778@mailhost.aber.ac.uk> From: D E PRICE Dear All, I often get asked why the (subjective) quality of internet video is not as good as ISDN video, even when the same bit rate is used. While I try to give an explanation, to be honest I am often puzzled why (say) ivs when running at 128Kbit/sec does not give output anywhere as near as good as a 128Kbit/sec ISDN connection when both are using H261 etc.... Can anyone offer some explanations please? Dave Price ----------------------------------------------------------------- | David Price, Computer Science | | | | Computer Science, University of Wales, Aberystwyth, | | Penglais Campus, Aberystwyth, Dyfed, SY23 3DB | | | | Janet: dap@uk.ac.aber Internet: dap@aber.ac.uk | | Phone: +44 970 622428 FAX: +44 970 622455 | ----------------------------------------------------------------- From rem-conf-request@es.net Mon Dec 19 23:07:14 1994 Received: from nexsys.nexsys.net by osi-west.es.net via ESnet SMTP service id <04557-0@osi-west.es.net>; Mon, 19 Dec 1994 20:06:39 +0000 Received: from localhost by nexsys.nexsys.net (8.6.5/SM-8.6.4) id UAA07283; Mon, 19 Dec 1994 20:05:49 -0800 Date: Mon, 19 Dec 1994 20:05:49 -0800 From: geoffw@nexsys.net (Geoff White) Message-Id: <199412200405.UAA07283@nexsys.nexsys.net> To: rem-conf@es.net Subject: 24 Hour House Music Marathon Dec 21 (0800 GMT) I'm trying to see if I can schedule some time for a stereo cybercast on the MBONE sometime between 0001 and 2359 hours PST on the 21st of December. Stanford University's college radio station is having their traditional 24 hour House music marathon, that they have on the winter solstice each year. I know that this is somewhat short notice, but I was refered to you by Ian Smith as someone who could help me (or at least tell me I'm wasting my time) as far as scheduling some time on a couple of the MBONE channels. Ideally we would like to cybercast the entire event but we are realistic and will take what ever we can get. Our preference would be near the end of the show (the last 6 hours) as that period will have the best DJ's performing. I am Director of Network Operations at InterNex so we have enough technical expertise to pull it off. Please drop me a line telling me what my options are (if any). I've used the experimental Mbone reservation web page at http://www.cilea.it/MBone/agenda.html to schedule this event but have heard no protest or response from anyone. Thanks, Geoff White From rem-conf-request@es.net Tue Dec 20 05:15:06 1994 Received: from charon.cwi.nl by osi-west.es.net via ESnet SMTP service id <07081-0@osi-west.es.net>; Tue, 20 Dec 1994 02:14:31 +0000 Received: from schelvis.cwi.nl by charon.cwi.nl with SMTP id ; Tue, 20 Dec 1994 11:14:25 +0100 Received: by schelvis.cwi.nl with SMTP id ; Tue, 20 Dec 1994 11:14:26 +0100 Message-Id: <9412201014.AA06539=jack@schelvis.cwi.nl> To: D E PRICE Cc: rem-conf@es.net Subject: Re: Sunjective Video Quality etc ? In-Reply-To: Message by D E PRICE , Mon, 19 Dec 1994 18:46:18 +0000 , <13624.787862778@mailhost.aber.ac.uk> Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam Phone: +31 20 5924098(work), +31 20 5924199 (fax), +31 20 6160335(home) X-Last-Band-Seen: Ex (Arena, 12-12) X-Mini-Review: Brilliant, brilliant, brilliant!!! Date: Tue, 20 Dec 1994 11:14:26 +0100 From: Jack Jansen Dave, have you tried running ivs on a 24-bit display? The dithering in ivs is not very good. With a 24 bit display the resulting picture is very good, usually. -- Jack Jansen | If I can't dance I don't want to be part of Jack.Jansen@cwi.nl | your revolution -- Emma Goldman uunet!cwi.nl!jack G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl From rem-conf-request@es.net Tue Dec 20 07:41:34 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <08059-0@osi-west.es.net>; Tue, 20 Dec 1994 04:40:49 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 20 Dec 1994 12:40:24 +0000 To: D E PRICE cc: rem-conf@es.net, mdt@aberystwyth.ac.uk Subject: Re: Sunjective Video Quality etc ? In-reply-to: Your message of "Mon, 19 Dec 94 18:46:18 GMT." <13624.787862778@mailhost.aber.ac.uk> Date: Tue, 20 Dec 94 12:40:22 +0000 Message-ID: <1885.787927222@cs.ucl.ac.uk> From: Jon Crowcroft > I often get asked why the (subjective) quality >of internet video is not as good as ISDN video, even when >the same bit rate is used. While I try to give an explanation, >to be honest I am often puzzled why (say) ivs when running >at 128Kbit/sec does not give output anywhere as near as >good as a 128Kbit/sec ISDN connection when both are using >H261 etc.... > Can anyone offer some explanations please? Dave yes..... 1/ measure goodput (received rate) - the internet is pretty lossy! 2/ look at the delay variation 3/ you're comparing a s/w codec with a h/w codec 0 many of the h/w codecs do image enahcenement (e.g. increase contrast to sharpen edges, or even soften edges) before applying H.261 to get better results try ivs over IP over 2 B channel ISDN call, and then compare! jon From rem-conf-request@es.net Tue Dec 20 08:44:39 1994 Received: from jerry.inria.fr by osi-west.es.net via ESnet SMTP service id <08349-0@osi-west.es.net>; Tue, 20 Dec 1994 05:43:41 +0000 Received: by jerry.inria.fr (5.65c8/IDA-1.2.8) id AA10038; Tue, 20 Dec 1994 14:43:07 +0100 Message-Id: <199412201343.AA10038@jerry.inria.fr> To: D E PRICE Cc: Jack Jansen , rem-conf@es.net Subject: Re: Sunjective Video Quality etc ? In-Reply-To: Your message of Mon, 19 Dec 1994 18:46:18 +0000. <13624.787862778@mailhost.aber.ac.uk> Reply-To: Thierry.Turletti@sophia.inria.fr Date: Tue, 20 Dec 1994 14:43:05 +0100 From: Thierry Turletti > I often get asked why the (subjective) quality >of internet video is not as good as ISDN video, even when >the same bit rate is used. While I try to give an explanation, >to be honest I am often puzzled why (say) ivs when running >at 128Kbit/sec does not give output anywhere as near as >good as a 128Kbit/sec ISDN connection when both are using >H261 etc.... There are several possible explanations: - On the Internet, you are using a best effort service and you don't reserve any bandwidth for your transmission. So, you may observe a high packet loss rate which affects the image quality. - When you run a ISDN video at 128 kbps, the output rate is equal to 128 kbps throughout the duration of the transmission. The output rate of ivs is variable, and in fact you can specify a *maximal* output rate (e.g. 128 kbps) but this does not mean that the actual output rate is always equal to 128 kpbs. Rather, it will be varying say between 15 kbps (the min output rate) and 128 kbps during your transmission. The reason is there is no smooth buffer at the output of the coder. So, the variable bit rate depends on o the movement in the video scene encoded o the type of scene encoded o the cpu of your machine - The rate control algorithm of your ISDN video codec might be better than ivs' rate control algorithm. The H.261 specification does not specify the way to adjust the video output rate. Currently, ivs uses the quantizer value and the movement detection threshold in the ``Privilege Frame rate'' mode and delays packets in the ``Privilege Quality'' mode. For example, when a high movement detection threshold is selected, sensitivity to movement in the scene is reduced and contours are affected. - The dithering algorithm mentioned by Jack Jansen. BTW, ivs has been gradually improved since the first version and the 3.3 version will not be the last version ... Thierry Turletti From rem-conf-request@es.net Tue Dec 20 19:45:43 1994 Received: from bsdi.sccsi.com by osi-west.es.net via ESnet SMTP service id <14534-0@osi-west.es.net>; Tue, 20 Dec 1994 16:45:04 +0000 Received: (darren@localhost) by bsdi.sccsi.com (8.6.8.1/8.6.5) id SAA28174 for rem-conf@es.net; Tue, 20 Dec 1994 18:44:41 -0600 From: Darren Bolding Message-Id: <199412210044.SAA28174@bsdi.sccsi.com> Subject: [Q] Stock info. To: rem-conf@es.net Date: Tue, 20 Dec 1994 18:44:40 -0600 (CST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1808 This may not be entirely the right place, but perhaps you can direct me to the appropriate one if it is incorrect. Further, it may not be a bright question- if it is not, please enlighten me so that I don't err again. ;) I came upon something nifty today and it set me to thinking. I was looking over an InterNic scout report (neat new things on the net) and saw that a company is now offering 15 minute delayed stock quotes via the net (http://www.secapl.com/cgi-bin/qs) for free. Now, this set me to thinking; they say they have tickertape ability as well as supporting request/reply, but I didn't see it. Anyway, I decided that sending http requests and then getting answers would be inneficient at any usefull tickertape speed (a formalization of this would require assumptions about how one could restrain the content and frequency of the tickertape information). So, I thought that putting this sort of information on a multicast address might just be the most efficent method, in a perfect world. But, how many people who would want to receive such information actually can use the Mbone, and would simoltaneously providing link oriented service be ineficient? Again, my limitted understanding of IP Multicast sugests that any formal answer to this question would require some assumptions about usage. Either way, it seems like Xstock might be pretty nifty, and if designed correctly, a good example of how Multicast can be used to provide information that the business community would find *usefull*, and that might not be bad. Comments are of course welcome. -- Darren Bolding UNIX, Network, Security, Telecom Consulting/Contracting darren@bsdi.sccsi.com Paranet Inc. Houston, TX 1-800-752-3475 My NIS domain is bigger than yours. Currently Stationed: Frigid Chicago From rem-conf-request@es.net Wed Dec 21 00:48:39 1994 Received: from u-aizugw-hub.u-aizu.ac.jp by osi-west.es.net via ESnet SMTP service id <16369-0@osi-west.es.net>; Tue, 20 Dec 1994 21:47:59 +0000 Received: from pross114.u-aizu.ac.jp (pross114.u-aizu.ac.jp [163.143.180.102]) by u-aizugw1.u-aizu.ac.jp (8.6.9+2.4Wb/3.2W-u-aizugw.u-aizu.ac.jp03/30/94) with ESMTP id OAA19691; Wed, 21 Dec 1994 14:36:18 +0900 Received: from localhost (localhost [127.0.0.1]) by pross114.u-aizu.ac.jp (8.6.5+2.3W/3.2W-rsvss2.u-aizu.ac.jp03/17/94) with ESMTP id OAA20055; Wed, 21 Dec 1994 14:35:58 +0900 Message-Id: <199412210535.OAA20055@pross114.u-aizu.ac.jp> To: end2end-interest@isi.edu, f-troup@aurora.cis.upenn.edu, rem-conf-request@es.net, cost237-transport@comp.lancs.ac.uk, reres@laas.fr, hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca, rem-conf@es.net, sigmedia@bellcore.com, tccc@cs.umass.edu Subject: MmNet95 Call for Papers, please distribute. Happy holidays!! Date: Wed, 21 Dec 1994 14:35:58 +0900 From: Behcet Sarikaya CALL FOR PAPERS - MMNET'95 The International Conference on Multimedia Networking Aizu-Wakamatsu, Fukushima, Japan (27-29 September 1995) SCOPE and OBJECTIVE ------------------- The University of Aizu was founded in 1993 by the Fukushima Government. It presently has two departments: Computer Hardware and Computer Software. The conference is being launched to promote research on multimedia and networking. Topics of interests include the following for which original research papers are solicited: A. Network and Operating System Support for Multimedia B. Teleservices, Multimedia mail C. Quality of Service Issues and Architectures D. Media Scheduling and Synchronization Techniques E. Broadband Network Transport Issues F. Synchronization Mechanisms G. Distributed Multimedia Systems H. Multimedia Models, Frameworks, and Document Architectures I. Multimedia in Personal Communication Systems VENUE ----- The conference will be held on the campus of the University of Aizu. The University of Aizu is located in Aizu-Wakamatsu City, 300 km northwest of Tokyo. Aizu-Wakamatsu can easily be reached from Tokyo or other major cities in Japan via toll expressway. The Japanese bullet train (Shinkansen) from Tokyo stops in Koriyama which is 50 km east of Aizu-Wakamatsu and a local train connects Koriyama to Aizu-Wakamatsu. Aizu-Wakamatsu is the historic capital of the Aizu region of Fukushima Prefecture and is in the scenic vicinity of the Bandai-Asahi National Park. Aizu region is famous for its hot springs, skiing resorts and the Japanese wine, sake. The average daily high temperature in September is about 20 degrees Celsius (about 70 degrees F). CONTRIBUTIONS ------------- IMPORTANT DATES: - April 28, 1995: Submission of papers - June 9, 1995: Authors will be notified - July 12, 1995: Camera-ready papers will be due The papers should not exceed 12 pages single-spaced. The front page should contain the author(s)'s name(s), affiliation, address, phone, fax and email, as well as an informative abstract. The proceedings will be published by the IEEE Computer Society Press. Please submit the papers by email to mmnet95@u-aizu.ac.jp in (printable) postscript form by April 28, 1995. ====================================================================== CONFERENCE CHAIR. Makoto Ikeda, University of Aizu PROGRAM CHAIR. Behcet Sarikaya, University of Aizu PROGRAM COMMITTEE. ------------------ Ian F. Akyildiz (Georgia Tech, USA), Geoff Coulson (Lancaster University, UK) Jean-Pierre Courtiat (LAAS, France), Wolfgang Effelsberg (University of Mannheim, Germany) Masaki Ito (NTT-Tokyo, Japan) Lian Li (Bell Northern Research-Ottawa, Canada) Tom D.C. Little (Boston University, USA) Shiro Sakata (NEC-Kawasaki, Japan) Aruna Seneviratne (Univ. of Technology, Australia) Ralf Steinmetz (IBM-Heidelberg, Germany) LOCAL ARRANGEMENTS CHAIR. Senro Saito, University of Aizu For further information, please contact Behcet Sarikaya via email: sarikaya@u-aizu.ac.jp, fax: (81) 242-37-2742 phone: (81) 242-37-2559 or by post Behcet Sarikaya The University of Aizu Tsuruga, Ikki-machi Aizu-Wakamatsu Shi, Fukushima Ken Japan 965-80. From rem-conf-request@es.net Wed Dec 21 10:42:35 1994 Received: from LL.MIT.EDU by osi-west.es.net via ESnet SMTP service id <20420-0@osi-west.es.net>; Wed, 21 Dec 1994 07:41:56 +0000 Received: by ll.mit.edu (4.1/LL-1.3) id AA11558; Wed, 21 Dec 94 10:38:40 EST Return-Path: X-Sender: dougm@nearlink.llan Message-Id: <9412211038.AA26680@LL.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Dec 94 10:38:39 -0500 To: rem-conf@es.net From: marquis@ll.mit.edu (Doug Marquis) Subject: Re: [Q] Stock info. >I came upon something nifty today and it set me to thinking. I was >looking over an InterNic scout report (neat new things on the net) and >saw that a company is now offering 15 minute delayed stock quotes via >the net (http://www.secapl.com/cgi-bin/qs) for free. [deleted] >So, I thought that putting this sort of information on a multicast >address might just be the most efficent method, in a perfect world. >[deleted] Though I don't represent them, the data is provided by North American Quotations, Inc. 15 minute delayed data is available free from a number of sources. I'd check carefully with the data provider before designing a system that multicasts their data automatically to a large set of users over internet (thus potentially undercutting other parts of their business, perhaps some who subscribed to pay-as-you-play services might quit them were this freely available). Perhaps those providers wouldn't mind your idea, perhaps they would. Not withstanding the above comment, there may be good applications for internet multicast other than the MBONE, which have not yet been explored. Any ideas? -*- Doug -*- marquis@ll.mit.edu From rem-conf-request@es.net Wed Dec 21 12:54:03 1994 Received: from bsdi.sccsi.com by osi-west.es.net via ESnet SMTP service id <21460-0@osi-west.es.net>; Wed, 21 Dec 1994 09:53:21 +0000 Received: (darren@localhost) by bsdi.sccsi.com (8.6.8.1/8.6.5) id LAA01492; Wed, 21 Dec 1994 11:53:17 -0600 From: Darren Bolding Message-Id: <199412211753.LAA01492@bsdi.sccsi.com> Subject: Re: [Q] Stock info. To: marquis@ll.mit.edu (Doug Marquis) Date: Wed, 21 Dec 1994 11:53:16 -0600 (CST) Cc: rem-conf@es.net In-Reply-To: <9412211038.AA26680@LL.MIT.EDU> from "Doug Marquis" at Dec 21, 94 10:38:39 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1918 In the previous message, Doug Marquis said: > > >So, I thought that putting this sort of information on a multicast > >address might just be the most efficent method, in a perfect world. > >[deleted] > > Though I don't represent them, the data is provided by North American > Quotations, Inc. 15 minute delayed data is available free from a number of > sources. > > I'd check carefully with the data provider before designing a system that > multicasts their data automatically to a large set of users over internet > (thus potentially undercutting other parts of their business, perhaps some > who subscribed to pay-as-you-play services might quit them were this freely > available). Perhaps those providers wouldn't mind your idea, perhaps they > would. Oh, I wasn't planning on implementing something like this without *lots* of documented evidence saying its OK etc. Although I certainly do appreciate the warning- its always nice to get good advice! I'm also not committing to develop this product, or trying to keep anyone else from starting :) :) :) I'm pretty busy with all kinds of projects, I would have to pursue something like this in my spare time. > > Not withstanding the above comment, there may be good applications for > internet multicast other than the MBONE, which have not yet been explored. > Any ideas? > > -*- Doug -*- > marquis@ll.mit.edu > Well, I've heard the idea of auctions mentioned and a friend implemented a multicast talk application. It might also work for distribution of usenet news; but I think the current framework of servers would make that a bad idea (tm). -- Darren Bolding UNIX, Network, Security, Telecom Consulting/Contracting darren@bsdi.sccsi.com Paranet Inc. Houston, TX 1-800-752-3475 My NIS domain is bigger than yours. Currently Stationed: Frigid Chicago From rem-conf-request@es.net Wed Dec 21 13:02:02 1994 Received: from noc.BelWue.DE by osi-west.es.net via ESnet SMTP service id <21580-0@osi-west.es.net>; Wed, 21 Dec 1994 10:01:07 +0000 Received: from ipx4.rz.uni-mannheim.de by noc.BelWue.DE with SMTP id AA06694 (5.65c8/IDA-1.4.4 for ); Wed, 21 Dec 1994 19:01:01 +0100 Received: by ipx4.rz.uni-mannheim.de (4.1/BelWue-1.1Sma1(subsidiary)) id AA15144; Wed, 21 Dec 94 19:01:58 +0100 Date: Wed, 21 Dec 1994 19:01:57 +0100 (MET) From: Peter Heiligers Subject: sd for linux ? To: rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Is there already an sd, vat etc. for linux available somewhere ? Linux supports ip-multicasting since version 1.1.73., nv is already available and working. Thanks Peter ------------------------------------------------------------------- Peter Heiligers Email: heiligers@rz.uni-mannheim.de Computing Center Tel.: ++49-621-2921434 University Mannheim FAX: ++49-621-2925783 L15, 16 68131 Mannheim From rem-conf-request@es.net Wed Dec 21 13:57:40 1994 Received: from cathedral.cerc.wvu.edu by osi-west.es.net via ESnet SMTP service id <22094-0@osi-west.es.net>; Wed, 21 Dec 1994 10:55:43 +0000 Received: from coal (coal.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA02874; Wed, 21 Dec 94 13:55:31 EST From: callahan@cerc.wvu.edu (Jack R. Callahan) Received: by coal (5.0//ident-1.0) id AA11277; Wed, 21 Dec 1994 13:52:32 +0500 Message-Id: <9412211852.AA11277@coal> Subject: Re: [Q] Stock info. To: marquis@ll.mit.edu (Doug Marquis) Date: Wed, 21 Dec 1994 13:52:28 -0500 (EST) Cc: rem-conf@es.net In-Reply-To: <9412211038.AA26680@LL.MIT.EDU> from "Doug Marquis" at Dec 21, 94 10:38:39 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2624 > > Not withstanding the above comment, there may be good applications for > internet multicast other than the MBONE, which have not yet been explored. > Any ideas? > > -*- Doug -*- > marquis@ll.mit.edu > > > Actually, I had a class of mine design and implement a multicast tool for a software engineering project last semester. The tool is called IML - Internet Multicast Locator. The tool periodically sends unreliable multicast packets on a well-known address that advertise the name, latitude, longitude and some other attributes of the user. The user interface is a world map implemented in Tk that can be zoomed, unzoomed, and scrolled. Only country boundaries are currently shown - not states or provinces. Each site appears as a red dot on the map. Analogous to vat, a site blinks when a packet is received and fades to gray and eventually disappears when a packet hasn't been received within a threshold time period. Below the world map is a list of sites within the current view. If you zoom in on a region, the current view list is updated to include only those sites within the map window. I created IML because I was tired of "scanning" sd and vat for people's names to check if they were on the MBone when I knew where they were geographically. I wanted a tool to quickly check if a person was up or not by their physical location. We still have some problems/wishes with IML: * The current view and zooming still has problems updating; * Overlap of sites within a small area. For example, within Morgantown, WV at WVU we LOTS of workstations, but representing each as slightly different lat/long it is still VERY difficult to differentiate machines. We are thinking of consolidating all machines within an area into a single red dot; * We would like to have icons instead of red dots to represent sites; * We would like to use additional attributes to "filter" sites (e.g., show all "UNIX" sites in green, ...); * more problems/wishes... My class was split into two teams and did the project in parallel. One team's solution was much better than the other. I have not had time to get the tool ready for release and more work needs to be done to get the tool in shape for release. I would be willing to release the existing code and collaborate if me and my students are given the appropriate attribution :-). -- jack Jack Callahan Assistant Professor Dept. of Statistics and Computer Science West Virginia University Morgantown, WV 26506-6330 callahan@cs.wvu.edu 304-293-7226 (x286) From rem-conf-request@es.net Wed Dec 21 16:42:16 1994 Received: from touchstone.power.net by osi-west.es.net via ESnet SMTP service id <23716-0@osi-west.es.net>; Wed, 21 Dec 1994 13:41:13 +0000 Received: by power.net (Smail3.1.28.1 #11) id m0rKYmR-000szEC; Wed, 21 Dec 94 13:41 PST Date: Wed, 21 Dec 1994 13:41:07 -0800 (PST) From: Elias Levy To: Peter Heiligers cc: rem-conf@es.net Subject: Re: sd for linux ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 21 Dec 1994, Peter Heiligers wrote: I was able to port nv and partialy port ivs, I belive that sd is already ported. More impotant would be to ask has anyone been able to port mrouted to linux? I gave it a shot and came short on igmp.c. Its using a structure called ip that I suppose is the header for ip datagrams. I could not find something similar in the linux include files or kernel source. > > Is there already an sd, vat etc. for linux available somewhere ? > Linux supports ip-multicasting since version 1.1.73., nv is already > available and working. > > Thanks Peter > > ------------------------------------------------------------------- > Peter Heiligers Email: heiligers@rz.uni-mannheim.de > Computing Center Tel.: ++49-621-2921434 > University Mannheim FAX: ++49-621-2925783 > L15, 16 > 68131 Mannheim > > > elias@power.net (Elias Levy) PowerNet, Inc. From rem-conf-request@es.net Wed Dec 21 17:34:15 1994 Received: from bsdi.sccsi.com by osi-west.es.net via ESnet SMTP service id <24289-0@osi-west.es.net>; Wed, 21 Dec 1994 14:33:00 +0000 Received: (darren@localhost) by bsdi.sccsi.com (8.6.8.1/8.6.5) id QAA02802 for rem-conf@es.net; Wed, 21 Dec 1994 16:32:52 -0600 From: Darren Bolding Message-Id: <199412212232.QAA02802@bsdi.sccsi.com> Subject: Non-MBONE uses (was Re: [Q] Stock info.) To: rem-conf@es.net Date: Wed, 21 Dec 1994 16:32:51 -0600 (CST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1108 Ok, a couiple people have commented that they think stock quotes would be a reasonable example of a non-Mbone use of ip multicast. While I'm interested in the idea myself, and think it is something I would like to be a part of trial developing (even if we can't get real stock data, the model would probably hold when/if we do). However, this raises a couple of questions. 1) Is this the appropriate forum? 2) Are there other docs than Dr. Deering's paper etc. on it? The FAQ is ancient, and the "what is multicast" paper is about the same age. While I'm *fine* with learning from other code, I don't want to miss a resource. 3) I've noticed that it seems like most of these tools are based on tcl/tk; has someone already implemented multicast IP extensions to tcl? If not, wouldn't this be a good first step, since it would make other apps that much easier to write? -- Darren Bolding UNIX, Network, Security, Telecom Consulting/Contracting darren@bsdi.sccsi.com Paranet Inc. Houston, TX 1-800-752-3475 My NIS domain is bigger than yours. Currently Stationed: Frigid Chicago From rem-conf-request@es.net Wed Dec 21 18:57:36 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <25485-0@osi-west.es.net>; Wed, 21 Dec 1994 15:56:11 +0000 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14673(7)>; Wed, 21 Dec 1994 15:53:36 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12172>; Wed, 21 Dec 1994 15:52:45 -0800 To: marquis@ll.mit.edu (Doug Marquis) Cc: rem-conf@es.net, deering@parc.xerox.com Subject: Re: [Q] Stock info. In-reply-to: marquis's message of Wed, 21 Dec 94 07:38:39 -0800. <9412211038.AA26680@LL.MIT.EDU> Date: Wed, 21 Dec 1994 15:52:33 PST Sender: Steve Deering From: Steve Deering Message-Id: <94Dec21.155245pst.12172@skylark.parc.xerox.com> Doug, > Not withstanding the above comment, there may be good applications for > internet multicast other than the MBONE, which have not yet been explored. The MBone is the general-purpose infrastructure that enables IP multicast delivery across the Internet; it is not an application or a specific suite of applications. If you want to multicast stock quote information over the big-I Internet, the MBone is what you should use to accomplish that. Steve From rem-conf-request@es.net Wed Dec 21 19:41:23 1994 Received: from adept.PRPA.Philips.COM by osi-west.es.net via ESnet SMTP service id <26285-0@osi-west.es.net>; Wed, 21 Dec 1994 16:39:55 +0000 Received: from jeanet.PRPA.Philips.COM by adept.PRPA.Philips.COM (4.1/SMI-4.1) id AA04473; Wed, 21 Dec 94 16:39:53 PST Received: by jeanet.PRPA.Philips.COM (4.1/SMI-4.1) id AA05833; Wed, 21 Dec 94 16:40:06 PST Date: Wed, 21 Dec 94 16:40:06 PST From: nichols@jeanet.PRPA.Philips.COM (Kathleen Nichols) Message-Id: <9412220040.AA05833@jeanet.PRPA.Philips.COM> To: rem-conf@es.net Subject: Call for Papers, Hot Interconnects III CALL FOR CONTRIBUTIONS A Symposium on High Performance Interconnects HOT INTERCONNECTS III SYMPOSIUM August 10-12, 1995 Stanford University, Palo Alto, CA Hot Interconnects is an international symposium focusing on the architecture and implementation of high-performance interconnects of all scales. Hot Interconnects III will emphasize real solutions, not theoretical designs. The conference will include a broad technical program and provide a format for professionals working on a range of interconnect types to share experiences. Contributions should focus on real products, prototypes, or experimental systems and their performance evaluation. The top papers, as judged by attendee rankings, will be considered for a special issue of the IEEE MICRO devoted to Hot Interconnects. Technical areas for Hot Interconnects III include, but are not limited to: Processor-memory interconnects LAN, DAN, WAN, MAN architectures Multiprocessor and MPP interconnects Multimedia and Real-Time support Processor-network interface issues Performance evaluation of interconnects Operating systems issues Scalability and reliability issues Chip sets and building blocks Wireless and mobile interconnects Flow control algorithms Routing, addressing, naming and binding Since the symposium program will include both leading edge product descriptions and more traditional technical papers, there will be two submission formats. Product/prototype submissions should consist of an abstract of 3-5 pages describing the product and why it is interesting; a copy of the presentation overheads will be included in the symposium proceedings. Technical paper submissions should consist of a 4-6 page extended abstract; a full paper of up to ten pages must be submitted for the proceedings following acceptance. Submissions will be reviewed by the program committee and our reviewers. All submissions must include the name, title, address, phone number, fax number, and electronic mail address of the presenter. The type of submission, presentation-only or full-paper, should be clearly indicated. In the case of unannounced products, if the information is to be kept confidential, please indicate so and every effort will be made to maintain confidentiality. Tutorial proposals are also being solicited for full or half-day tutorials. Proposals should include a brief description of the intended audience, a lecture outline, and vita for the lecturer. The deadline for submissions is February 27, 1995. Authors and speakers will be notified of acceptance by May 5, 1995. Final copy for full-length papers and presentation overheads will be due on July 21, 1995. Submissions can be made by sending 10 copies via surface mail to arrive no later than February 27,1995. Submissions should be addressed to: Prof. Tom Anderson Computer Science Division, UC Berkeley Berkeley, CA 94720 hoti@cs.berkeley.edu For further information about submissions, contact: Dr. Vivian Shen Fax: (415) 857-8526 HP Labs Voice: (415) 857-6307 1501 Page Mill Road email: vivians@hpl.hp.com Palo Alto, Ca. 94304 General Chair: Dr. Kathleen Nichols, Philips Research hoti@prpa.philips.com Program Co-Chairs Prof. Tom Anderson, UC Berkeley Dr. Vivian Shen, HP Labs Hot Interconnects III information is available on the World Wide Web at: http://now.cs.berkeley.edu/pub/html/HotI From rem-conf-request@es.net Wed Dec 21 23:50:13 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <28028-0@osi-west.es.net>; Wed, 21 Dec 1994 20:49:25 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 21 Dec 1994 20:49:18 -0800 Posted-Date: Wed 21 Dec 94 20:48:07 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Wed, 21 Dec 94 20:48:08 PST Date: Wed 21 Dec 94 20:48:07 PST From: Stephen Casner Subject: National Information Infrastructure Awards To: rem-conf@es.net, MBONE@ISI.EDU Cc: epalmer@earthlink.net Message-Id: <788071687.0.CASNER@XFR.ISI.EDU> Mail-System-Version: After seeing the article about MBone in Newsweek, Elaine Palmer of Access Media contacted me about the National Information Infrastructure Awards: The NII Awards will recognize uses of the "information highway" that powerfully demonstrate its capabilities and utility: real examples and success stories that illustrate the NII's potential to provide new benefits and encourage communication, collaboration and access to information beyond traditional boundaries. She suggested that I submit an entry, but on more careful reading of the intent, they are not looking for "the MBone" or "vat" as an entry. Rather, they would like entries describing some of the most compelling uses of the MBone and/or the audio/video tools. So, I'm passing this message on to the larger MBone community. There is no entry fee, but some writing is required. For more info, contact the automated server at info-request@niiawards.org . -- Steve ------- From rem-conf-request@es.net Thu Dec 22 00:30:48 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <28316-0@osi-west.es.net>; Wed, 21 Dec 1994 21:30:03 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Wed, 21 Dec 1994 21:29:57 -0800 Posted-Date: Wed 21 Dec 94 21:28:47 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Wed, 21 Dec 94 21:28:47 PST Date: Wed 21 Dec 94 21:28:47 PST From: Stephen Casner Subject: Re: Non-MBONE uses (was Re: [Q] Stock info.) To: darren@sccsi.com, rem-conf@es.net Message-Id: <788074127.0.CASNER@XFR.ISI.EDU> In-Reply-To: <199412212232.QAA02802@bsdi.sccsi.com> Mail-System-Version: > From: Darren Bolding > Date: Wed, 21 Dec 1994 16:32:51 -0600 (CST) > Ok, a couiple people have commented that they think stock quotes would > be a reasonable example of a non-Mbone use of ip multicast. As Steve Deering pointed out, what you really mean is "non-audio/video use of ip multicast". If you want to do worldwide IP multicast, the MBone (= Multicast Backbone, not multimedia backbone) is how you do it. The MBone is a virtual network on top of the physical Internet, but over time, as IP multicast is deployed in the production routers of the Internet, the MBone as a separate entity will fade away. > 1) Is this the appropriate forum? I think so, but is a forum needed? > 2) Are there other docs than Dr. Deering's paper etc. on it? The FAQ > is ancient, and the "what is multicast" paper is about the same age. > While I'm *fine* with learning from other code, I don't want to miss > a resource. I admit that the MBone FAQ needs attention, but it was not intended to answer the questions you are asking here. Writing a program to spit out packets containing stock quotes (or anything else) is a simple exercise for which you could learn the basics by looking at other code. The complicated part is: - figuring out what bandwidth is reasonable to consume, and correspondingly what TTL should you use - determining what reliability mechanisms are needed if any - making sure you don't introduce any mechanisms (like retransmission requests) that will melt the network as the number of receivers grows - etc. That part isn't written down anywhere that I know of. By the way, Kurt Lidl and others at UUnet have already done multicast netnews. -- Steve ------- From rem-conf-request@es.net Thu Dec 22 03:34:53 1994 Received: from cs.tut.fi by osi-west.es.net via ESnet SMTP service id <29746-0@osi-west.es.net>; Thu, 22 Dec 1994 00:33:56 +0000 Received: from isosotka.cs.tut.fi (mit@isosotka.cs.tut.fi [130.230.17.14]) by cs.tut.fi (8.6.9/8.6.4) with ESMTP id KAA16865; Thu, 22 Dec 1994 10:36:50 +0200 From: Tsokkinen Mikko Received: (mit@localhost) by isosotka.cs.tut.fi (8.6.8/8.6.4) id KAA24929; Thu, 22 Dec 1994 10:36:51 +0200 Date: Thu, 22 Dec 1994 10:36:51 +0200 Message-Id: <199412220836.KAA24929@isosotka.cs.tut.fi> To: Peter Heiligers Cc: rem-conf@es.net Subject: Re: sd for linux ? In-Reply-To: References: Peter Heiligers writes: > >Is there already an sd, vat etc. for linux available somewhere ? >Linux supports ip-multicasting since version 1.1.73., nv is already >available and working. Good news! Is the multicast kernel build as described in RFC, i.e. does mrouted (2.2) work with it? How about pruning (mrouted3.3)? Mikko Tsokkinen Digital Media Institute, Tampere University of Technology Research Assistant - Project FASTER Distributed Multimedia Applications over ATM-Network From rem-conf-request@es.net Thu Dec 22 16:29:09 1994 Received: from newton.ncsa.uiuc.edu by osi-west.es.net via ESnet SMTP service id <06489-0@osi-west.es.net>; Thu, 22 Dec 1994 13:28:07 +0000 Received: from void.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA09892 (5.65a/IDA-1.4.2 for rem-conf@es.net); Thu, 22 Dec 94 15:24:51 -0600 Return-Path: Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1) id AA09140; Thu, 22 Dec 94 15:25:14 CST Message-Id: <9412222125.AA09140@void.ncsa.uiuc.edu> Subject: Rebroadcast of Chicago WWW sessions 1/9-1/13 To: mbone@isi.edu, rem-conf@es.net Date: Thu, 22 Dec 1994 15:25:13 -0600 (CST) Cc: likkai@ncsa.uiuc.edu (Jason Ng), rodgers@nlm.nih.gov From: Daniel Simms X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1376 Hello all, There has been some interest in rebroadcasting the sessions originally broadcast during the WWW conference in October. Before making a definate announcement, I'd like know if these were going to cause any huge conflicts with anyone. Thanks, Daniel > These are the proposed dates: > > For Europe: > Tape Date Local Time Universal Time > tape1 Mon Jan 9 05:00:00 CST 11:00:00 GMT > > tape2 Tue Jan 10 04:00:00 CST 10:00:00 GMT > tape3 Tue Jan 10 05:30:00 CST 11:30:00 GMT > > tape4 Wed Jan 11 04:00:00 CST 10:00:00 GMT > tape5 Wed Jan 11 05:30:00 CST 11:30:00 GMT > > tape6 Thu Jan 12 04:00:00 CST 10:00:00 GMT > tape7 Thu Jan 12 05:30:00 CST 11:30:00 GMT > > For West Coast, Austrailia, East Asia: > Tape Date Local Time Universal Time > tape1 Mon Jan 9 16:00:00 CST 22:00:00 GMT > > tape2 Tue Jan 10 16:00:00 CST 22:00:00 GMT > tape3 Tue Jan 10 17:30:00 CST 23:30:00 GMT > > tape4 Wed Jan 11 16:00:00 CST 22:00:00 GMT > tape5 Wed Jan 11 17:30:00 CST 23:30:00 GMT > > tape6 Thu Jan 12 16:00:00 CST 22:00:00 GMT > tape7 Thu Jan 12 17:30:00 CST 23:30:00 GMT > -- Daniel Simms "Life can only be understood backwards, dsimms@uiuc.edu but it must be lived forwards." (217) {244-6664,328-7060} -Kierkegaard From rem-conf-request@es.net Thu Dec 22 18:29:53 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <07566-0@osi-west.es.net>; Thu, 22 Dec 1994 15:28:50 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14683(6)>; Thu, 22 Dec 1994 15:28:05 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16152>; Thu, 22 Dec 1994 15:27:38 -0800 X-Mailer: exmh version 1.5 11/22/94 To: rem-conf@es.net Subject: Problem with J300 MME grab on nv 3.3beta on DEC Alpha Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Dec 1994 15:27:36 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <94Dec22.152738pst.16152@ecco.parc.xerox.com> Hello everyone... I've seen a few reports about a problem with a greenish tint when capturing data from the J300 card using the MME library on the DEC Alpha. This is a bug that I thought was fixed before the code when to beta, but somehow the fix didn't make it into the nvsrc-3.3beta.tar file. Included below is the patch you need to apply. Sorry for the mixup! *** /tmp/nv-3.3beta/j300_grab.c Tue Jun 21 08:50:49 1994 --- ./j300_grab.c Tue Aug 16 14:58:48 1994 *************** *** 170,178 **** if (xmit_color) { uv = (v >> 8) & 0xff; ! uv |= (((v >> 16) & 0xff00) & 0xff); ! uv |= (((v >> 24) & 0xff0000) & 0xff); ! uv |= (((v >> 32) & 0xff000000) & 0xff); *uvp++ = uv ^ 0x80808080; } } --- 170,178 ---- if (xmit_color) { uv = (v >> 8) & 0xff; ! uv |= ((v >> 16) & 0xff00); ! uv |= ((v >> 24) & 0xff0000); ! uv |= ((v >> 32) & 0xff000000); *uvp++ = uv ^ 0x80808080; } } -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Thu Dec 22 18:32:49 1994 Received: from trystero.radio.com by osi-west.es.net via ESnet SMTP service id <07658-0@osi-west.es.net>; Thu, 22 Dec 1994 15:31:38 +0000 Received: (carl@localhost) by trystero.radio.com (8.6.9/940816.06ccg) id SAA27152 for rem-conf@es.net; Thu, 22 Dec 1994 18:31:35 -0500 From: Carl Malamud Message-Id: <199412222331.SAA27152@trystero.radio.com> Subject: Messiah Multicast To: rem-conf@es.net Date: Thu, 22 Dec 1994 18:31:35 -0500 (EST) Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 375 The Messiah Multicast is on schedule for Friday, 12/23, but will start at 7:30PM instead of the usual 8:30PM start time for Kennedy Center events. As far as we can tell, this is going to happen: unions have signed off, the Bell Atlantic line appears to be working. You'll be able to access program details at: http://north.pole.org/santa/Messiah/ Merry Christmas, Carl From rem-conf-request@es.net Thu Dec 29 15:10:06 1994 Received: from 140.134.24.20 by osi-west.es.net via ESnet SMTP service id <10047-0@osi-west.es.net>; Mon, 26 Dec 1994 18:17:52 +0000 Received: by pine.iecs.fcu.edu.tw.IECS.FCU.edu.tw (4.1/SMI-4.1) id AA07756; Tue, 27 Dec 94 10:07:12 CST Date: Tue, 27 Dec 94 10:07:12 CST From: ycliaw@pine.IECS.FCU.edu.tw (Yi-Ching Liaw) Message-Id: <9412270207.AA07756@pine.iecs.fcu.edu.tw.IECS.FCU.edu.tw> To: rem-conf@es.net Please add me to the rem_conf list My_Email:ycliaw@pine.iecs.fcu.edu.tw My_Name :Yi-Ching Liaw From rem-conf-request@es.net Thu Dec 29 15:40:02 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <23313-0@osi-west.es.net>; Tue, 27 Dec 1994 17:46:21 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-20) id ; Tue, 27 Dec 1994 17:46:16 -0800 Posted-Date: Tue 27 Dec 94 17:44:56 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Tue, 27 Dec 94 17:44:57 PST Date: Tue 27 Dec 94 17:44:56 PST From: Stephen Casner Subject: Re: National Information Infrastructure Awards To: rem-conf@es.net, MBONE@ISI.EDU Message-Id: <788579096.0.CASNER@XFR.ISI.EDU> In-Reply-To: <788071687.0.CASNER@XFR.ISI.EDU> Mail-System-Version: I have received an update/correction on the automated server email address for information about the National Information Infrastructure Awards. It should be info@niiawards.org rather than -request as in the previous information I had received. -- Steve ------- From rem-conf-request@es.net Thu Dec 29 15:50:02 1994 Received: from vlsi.cs.caltech.edu by osi-west.es.net via ESnet SMTP service id <02205-0@osi-west.es.net>; Thu, 22 Dec 1994 18:00:18 +0000 Received: from fides.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1) id AA10869; Thu, 22 Dec 94 17:58:27 PST Date: Thu, 22 Dec 94 17:58:27 PST From: schooler@cs.caltech.edu (Eve Schooler) Message-Id: <9412230158.AA10869@vlsi.cs.caltech.edu> To: callahan@cerc.wvu.edu, rem-conf@es.net Subject: Re: Non-MBONE uses (was Re: [Q] Stock info.) Cc: schooler@cs.caltech.edu, casner@isi.edu, adam@cs.caltech.edu, khare@cs.caltech.edu In a previous message, Jack R. Callahan said: >Actually, I had a class of mine design and implement a multicast tool >for a software engineering project last semester. The tool is called >IML - Internet Multicast Locator. The tool periodically sends >unreliable multicast packets on a well-known address that advertise >the name, latitude, longitude and some other attributes of the user. > >The user interface is a world map implemented in Tk that can be >zoomed, unzoomed, and scrolled. Only country boundaries are currently >shown - not states or provinces. Each site appears as a red dot on >the map. Analogous to vat, a site blinks when a packet is received >and fades to gray and eventually disappears when a packet hasn't been >received within a threshold time period. Below the world map is a list >of sites within the current view. If you zoom in on a region, the >current view list is updated to include only those sites within the >map window. > >I created IML because I was tired of "scanning" sd and vat for >people's names to check if they were on the MBone when I knew where >they were geographically. I wanted a tool to quickly check if a >person was up or not by their physical location. I have implemented something similar in the latest version of MMCC, a session tool that orchestrates explicit-invitation calls and spawns familiar MBONE tools (e.g., vat, nv) to create non-public teleconferences. A recurring request from users has been to make it easier to find the addresses of others who were willing/able to "accept" calls; in other words, finding others who were running the tool. Originally, users could set up their own personal address book using a combination of a startup file, on-the-fly entry from the GUI, and automatic updates as new users called. To make it easier to boot-strap, we recently added a multicast address on which the users announce their availability at a particular locale and listen for remote users. Thus, it is quite similar to IML as a locator service, but instead of the GSP emphasis we try to track a user's locale for purposes of subsequent communication. This of course was inspired by sd and the control component of the RTP protocol. The idea was to apply these techniques to the user directory problem. Besides the known resiliency of a soft-state multicast approach, we use multicast announcements to obtain the appropriate TTL for reaching remote users and also to track mobility. Notably, we make user directory announcements at different TTL levels, so that each remote user stores the minimum TTL at which the announcement was first heard. When a session is created, MMCC selects the maximum of the minimum TTL values of all group members and passes this value to the associated media tools for proper scoping of the multicast real-time data. Because this feature is in prototype stages, we are not likely to release the new version more widely until we can solve some of the scaling issues (of which there are many!). Like IML, there are GUI issues for organizing lists of users and for filtering information. Additionally there are serious architecture and bandwidth issues. As Steve Casner stated in a previous message: >The complicated part is: > > - figuring out what bandwidth is reasonable to consume, and > correspondingly what TTL should you use > > - determining what reliability mechanisms are needed if any > > - making sure you don't introduce any mechanisms (like > retransmission requests) that will melt the network > as the number of receivers grows > > - etc. In the long term, I believe that a user locator service should be generalized so that many different types of applications can make use of it. Eve From rem-conf-request@es.net Thu Dec 29 16:10:07 1994 Received: from transfer.stratus.com by osi-west.es.net via ESnet SMTP service id <11163-0@osi-west.es.net>; Fri, 23 Dec 1994 15:19:18 +0000 Received: from cayuga.isis.stratus.com (cayuga.isis.stratus.com [198.97.41.54]) by transfer.stratus.com (8.6.9/8.6.9) with SMTP id SAA10850 for ; Fri, 23 Dec 1994 18:19:16 -0500 Received: by cayuga.isis.stratus.com (4.1/SMI-4.1-Isis-1.0) id AA28186; Fri, 23 Dec 94 18:19:15 EST Date: Fri, 23 Dec 94 18:19:15 EST From: jkay@isis.com (Jon Kay) Message-Id: <9412232319.AA28186@cayuga.isis.stratus.com> To: rem-conf@es.net Subject: Re: Non-MBONE uses marquis@ll.mit.edu questions: > Not withstanding the above comment, there may be good applications for > internet multicast other than the MBONE, which have not yet been explored. > Any ideas? There is a good application for internet multicast other than the Mbone which is being explored. Isis Distributed Systems (a commercialization of the Cornell Isis Toolkit) produces a distributed communication toolkit which has reliable multicast protocols with various levels of delivery ordering guarantees at its heart. In appropriate configurations it has code to take advantage of IP multicast. It is used in an assortment of financial and manufacturing applications. Assorted papers on the academic Isis may be found at http://www.cs.cornell.edu/Info/Projects/ISIS/ISIS.html Of course, as an employee of the company I make no claims to objectivity. Jon From rem-conf-request@es.net Thu Dec 29 16:50:03 1994 Received: from zuni.chaco.com by osi-west.es.net via ESnet SMTP service id <19847-0@osi-west.es.net>; Sat, 24 Dec 1994 14:29:15 +0000 Received: from hopi (hopi.chaco.com) by chaco.com (5.0/SMI-SVR4) id AA27717; Sat, 24 Dec 1994 14:29:27 +0800 Date: Sat, 24 Dec 1994 14:29:27 +0800 Message-Id: <9412242229.AA27717@chaco.com> X-Sender: coyote@chaco.com X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net, jkay@isis.com (Jon Kay) From: coyote@zuni.chaco.com (Ron Lussier) Subject: Joyous Solstice! content-length: 1739 Howdy Emily! It was nice getting your holiday card, and it's great hearing that you're having such a good time in Boston. Your card arrived just a tad too late, however, as two Fridays ago Dan and I were in Boston, speaking with a researcher at MIT. It would have been good to have lunch. We'll be out again soon, however, and when we are I hope we can get together. So are you 'out' at Lotus, or is that a barrier you haven't crossed yet? Lotus *is* a great company... the first in the country to give domestic partner benefits, if I remember correctly. Things have been happening here. The entire Appware team was layed off by Novell. Dan and I both got 6 months severence, which is great. Most of the best people went to NetManage, an internet software company (and probably a competitor of yours to some extent.) Dan and I, along with two other NetManage engineers, decided to start our own company, Chaco Communications. We're working on Internet-based gaming, and now NetManage is also *our* competitor. We're really excited about this. Not only is the product (my idea) exciting, but we got the two best programmers from the Windows team (myself and Pritham), the best Unix programmer, and Dan, who's great with C++ and Unix. We think that we can make a fortune if everything goes well. Chaco Communications, incidentally, takes its name from Chaco Canyon in New Mexico, a center of Anasazi culture and trading. I proposed to Dan there just after the last D.C. march. If you ever get a chance, it's a powerful place to visit. So anyhow, perhaps a year from now I may try to get you out to the west coast again, to work for Chaco. :-) I have to come out to see you... you must be so cute with spikey hair! Ron From rem-conf-request@es.net Thu Dec 29 16:50:06 1994 Received: from zuni.chaco.com by osi-west.es.net via ESnet SMTP service id <20917-0@osi-west.es.net>; Sat, 24 Dec 1994 17:14:28 +0000 Received: from hopi (hopi.chaco.com) by chaco.com (5.0/SMI-SVR4) id AA28455; Sat, 24 Dec 1994 17:14:39 +0800 Date: Sat, 24 Dec 1994 17:14:39 +0800 Message-Id: <9412250114.AA28455@chaco.com> X-Sender: coyote@chaco.com X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net, jkay@isis.com (Jon Kay) From: coyote@zuni.chaco.com (Ron Lussier) Subject: Howdy! content-length: 1739 Howdy Emily! It was nice getting your holiday card, and it's great hearing that you're having such a good time in Boston. Your card arrived just a tad too late, however, as two Fridays ago Dan and I were in Boston, speaking with a researcher at MIT. It would have been good to have lunch. We'll be out again soon, however, and when we are I hope we can get together. So are you 'out' at Lotus, or is that a barrier you haven't crossed yet? Lotus *is* a great company... the first in the country to give domestic partner benefits, if I remember correctly. Things have been happening here. The entire Appware team was layed off by Novell. Dan and I both got 6 months severence, which is great. Most of the best people went to NetManage, an internet software company (and probably a competitor of yours to some extent.) Dan and I, along with two other NetManage engineers, decided to start our own company, Chaco Communications. We're working on Internet-based gaming, and now NetManage is also *our* competitor. We're really excited about this. Not only is the product (my idea) exciting, but we got the two best programmers from the Windows team (myself and Pritham), the best Unix programmer, and Dan, who's great with C++ and Unix. We think that we can make a fortune if everything goes well. Chaco Communications, incidentally, takes its name from Chaco Canyon in New Mexico, a center of Anasazi culture and trading. I proposed to Dan there just after the last D.C. march. If you ever get a chance, it's a powerful place to visit. So anyhow, perhaps a year from now I may try to get you out to the west coast again, to work for Chaco. :-) I have to come out to see you... you must be so cute with spikey hair! Ron