From rem-conf-request@es.net Wed Jun 01 00:52:56 1994 Received: from taurus.cs.nps.navy.mil by osi-west.es.net via ESnet SMTP service id <03668-0@osi-west.es.net>; Tue, 31 May 1994 21:52:29 +0000 Received: from betsie.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA25556; Tue, 31 May 94 21:54:03 PDT Received: by betsie.cs.nps.navy.mil (931110.SGI/911001.SGI) for pratt@taurus.cs.nps.navy.mil id AA12396; Tue, 31 May 94 21:55:35 -0700 Date: Tue, 31 May 1994 21:55:34 -0700 (PDT) From: Michael Macedonia Sender: Michael Macedonia Reply-To: Michael Macedonia Subject: Multiplayer PC Games To: zyda Cc: npsnetrg@betsie.cs.nps.navy.mil, rem-conf@es.net, communications architecture subgroup Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Below is a list of Multiplayer *PC* games from the PC game FAQ. Point: Lots of games getting multiplayer capability. 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 ------------------------------------------------------------ --------------------------------------------------------------------------- 5.6: Which games have multi-player abilities? (From: Blair Prescott, Bjorn Halvorsen and others) There are a great number of PC games that can be played by multiple players, and more are being released all the time. They require use of a modem, null modem cable, IBM network, or just e-mail for their use. A partial list, including only the more popular games, follows here: 688 Attack Sub (modem/nullmodem) Air Duel (Dogfight) (???) Alien Breed (face-to-face) Armour Alley (1-4 players/modem/nullmodem) Battletris (nullmodem) Command HQ (modem/nullmodem) Conquered Kingdoms (???) Doom (modem/nullmodem/network) Dynablaster (1-4 players/face-to-face) Empire Deluxe (modem/nullmodem/email) F-15 Strike Eagle 3 (modem/nullmodem) F-29 Retaliator (modem/nullmodem) Falcon 3.0 (modem/network/nullmodem) Firepower (face-to-face) Global Conquest (1-4 players/modem/nullmodem) Graviton 2 (face-to-face) Howitzer (1-10 players/face-to-face) Knights in the Sky (???) The Lost Admiral (???) Microsoft Flight Simulator (modem?/nullmodem) Moraff's Ballgame (face-to-face) Mortal Kombat (face-to-face) Netspace (1-10 players/network) Perfect General (???) Populous (???) Populous (modem/nullmodem) Scorched Earth (1-10 players/face-to-face) Spaceward Ho! (1-20 players/network) Speedracer (face-to-face) Starcontrol 1 (face-to-face) Starcontrol 2: Ur-Quan Masters (face-to-face) SVGA Air Warrior (modem/nullmodem) Subworm (face-to-face) Tankkk (1-3 players/face-to-face) Tankwars (1-10 players/face-to-face) Tornado (modem/nullmodem) Tracon (modem/nullmodem) Ultris (face-to-face) VGA Planets (1-11 players/email) World Circuit (Formula 1 Grand Prix) (modem/nullmodem) From rem-conf-request@es.net Wed Jun 01 01:01:51 1994 Received: from PINYON.LIBRE.COM by osi-west.es.net via ESnet SMTP service id <03684-0@osi-west.es.net>; Tue, 31 May 1994 22:01:23 +0000 Received: from localhost (markeson@localhost) by pinyon.libre.com (8.6.4/8.6.4) id VAA00323; Tue, 31 May 1994 21:55:37 -0700 Date: Tue, 31 May 1994 21:54:45 -0700 (MST) From: Mark Markeson To: rem-conf@osi-west.es.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Please subscribe me to your mailing list. Thanks markeson@libre.com From rem-conf-request@es.net Wed Jun 01 03:14:08 1994 Received: from ceres.fokus.gmd.de by osi-west.es.net via ESnet SMTP service id <04071-0@osi-west.es.net>; Wed, 1 Jun 1994 00:13:43 +0000 Received: from fokus.gmd.de by ceres.fokus.gmd.de id <06176-0@ceres.fokus.gmd.de>; Wed, 1 Jun 1994 08:31:30 +0200 To: rem-conf@es.net, Andrew.Mills@amd.com Subject: Re: RTP/RTCP position in Stack Date: Wed, 1 Jun 1994 08:31:30 +0200 From: Henning Schulzrinne Sender: schulzrinne@fokus.gmd.de It's an interesting parlor game, but not necessarily particularly fruitful to try to decide how to map protocols not written by ISO into the OSI model. Many of the characteristics 'assigned' to layers come from a connection-oriented, data transport model and thus map particularly badly to 'new' services which are neither. With this caveat, my take on this would be that RTP, in combination with UDP or something similar, is a transport protocol; it's end-to-end, so it can't be a network protocol and it's really neither session (there is no notion of an RTP beginning or end, no three-way handshake, nothing) nor presentation, so that doesn't leave much else... Dividing layers into subprotocols seems to be fashionable these days, witness the seventeen sublayers of the ATM AAL :-). The timestamps could be considered part of the presentation layer since they determine delivery of data to the end user. RTCP provides what could be considered session functionality. The media encoding itself (or the structure of putting, say, DCT blocks into packets) is the 'presentation layer'. If you are looking for further confusion, try mapping ATM cell layer and AAL to OSI layers, particularly if you happen to believe in end-to-end ATM connectivity and like AAL 3/4 SSCOP... Henning From rem-conf-request@es.net Wed Jun 01 03:17:56 1994 Received: from sangam.ncst.ernet.in by osi-west.es.net via ESnet SMTP service id <04142-0@osi-west.es.net>; Wed, 1 Jun 1994 00:17:37 +0000 Received: (from uucp@localhost) by sangam.ncst.ernet.in (8.6.8.1/8.6.6) with UUCP id MAA03985 for rem-conf@es.net; Wed, 1 Jun 1994 12:47:18 +0530 Received: by henna.iitd.ernet.in (4.1/SMI-4.1-MHS-7.0 ) id AA10798; Wed, 1 Jun 94 12:42:18 IST X-Organisation: Indian Institute of Technology, New Delhi. Date: Wed, 1 Jun 1994 12:35:31 +0530 (IST) From: Palepu Srinivas Subject: PADDS To: rem-conf@es.net In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I am interested in knowing more about PADDS, supposed to be a distributed systems engineering tool, designed by Bertran and others at UPC. Or, may be, some other such system, preferably available as a public domain software or if someone needs an alpha- or a beta- test site. Thanks in advance. ============================================================================= Srinivas Palepu palepu@henna.iitd.ernet.in Ph: (W) +91-11-686 7431 Deptt of Comp.Sc & Engg Voice Mail +91-11-376 0520 IIT Hauz Khas, N.Delhi-16 Fax +91-11-686 8765 ----------------------------------------------------------------------------- From rem-conf-request@es.net Wed Jun 01 14:10:07 1994 Received: from MARIESUN.BBN.COM by osi-west.es.net via ESnet SMTP service id <05862-0@osi-west.es.net>; Wed, 1 Jun 1994 11:09:44 +0000 To: Kim Cohan cc: rem-conf@es.net, leekil@BBN.COM Subject: Re: 25 meter crane for holography lecture In-reply-to: Your message of Tue, 31 May 94 19:24:00 -0800. Date: Wed, 01 Jun 94 14:05:46 -0400 From: "Lee S. Kilpatrick" (Mr. Breeze) > News from the Carl Cherry Center holography lecture: > A local erection company (I love that word) "company"? Lee From rem-conf-request@es.net Wed Jun 01 14:18:40 1994 Received: from living.rutgers.edu by osi-west.es.net via ESnet SMTP service id <05915-0@osi-west.es.net>; Wed, 1 Jun 1994 11:18:15 +0000 Received: by living.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01734; Wed, 1 Jun 94 14:18:08 EDT Date: Wed, 1 Jun 94 14:18:08 EDT From: klemets@paul.rutgers.edu (Anders Klemets) Message-Id: <9406011818.AA01734@living.rutgers.edu> To: rem-conf@es.net Subject: Media on Demand paper I like to bring to your attention that I wrote a paper on the the design of my WWW-based "Media on Demand" system. It was presented last week at WWW'94, a USENIX-style conference on WWW. The paper is really just a quick hack, like much of my software, but if you want to check it out, nevertheless, the HTML version is at http://www.it.kth.se/~klemets/www.html and the postscript is in http://www.it.kth.se/~klemets/www94/www94.ps Should you for some reason be unable to retrieve documents using WWW, mail me and I'll put it up for ftp. Anders From rem-conf-request@es.net Wed Jun 01 16:41:58 1994 Received: from dns1.eecs.wsu.edu by osi-west.es.net via ESnet SMTP service id <02024-0@osi-west.es.net>; Wed, 1 Jun 1994 13:41:15 +0000 Received: from piggy.eecs.wsu.edu by dns1.eecs.wsu.edu (8.6.8.1/8.940415) id NAA26766; Wed, 1 Jun 1994 13:41:11 -0700 From: Tim Heldt Received: by piggy.eecs.wsu.edu (1.38.193.4) id AA27151; Wed, 1 Jun 1994 13:41:10 -0700 Message-Id: <9406012041.AA27151@piggy.eecs.wsu.edu> Subject: HPUX 9.03 and HP 712/60 To: rem-conf@es.net Date: Wed, 1 Jun 1994 13:41:10 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23beta3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 792 I am looking for the kernel mods for HPUX 9.03 and an HP9000/712 60 for IP Multicasting. Any idea if they exist? I have the 9.01 mods and they do not work. Thanks in advance, Tim -- +-------------------------------------------------------+ | Tim Heldt heldt@eecs.wsu.edu | | | | School of Electrical Engineering and Computer Science | | Washington State University | | Pullman, WA 99164-2752 | | | | Voice: (509) 335-6603 | | Fax: (509) 335-3818 | +-------------------------------------------------------+ From rem-conf-request@es.net Wed Jun 01 22:09:38 1994 Received: from ell.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <03616-0@osi-west.es.net>; Wed, 1 Jun 1994 19:09:13 +0000 Received: by ell.ee.lbl.gov (8.6.8.1/1.43r) id TAA09907; Wed, 1 Jun 1994 19:09:08 -0700 From: mccanne@ee.lbl.gov (Steven McCanne) Message-Id: <199406020209.TAA09907@ell.ee.lbl.gov> To: rem-conf@es.net Subject: new vat (v3.3) available for anonymous ftp Date: Wed, 01 Jun 94 19:09:07 PDT There's a new version of vat available for anonymous ftp from ftp.ee.lbl.gov in conferencing/vat/*-vat-3.3.tar.Z. This release fixes a couple of long standing incompatibilities with AudioFile and the multicast socket options. Vat is now linked against the R3 AudioFile library -- it will not work with an R2 server. Additionally, it now works on systems that do not use the standard encodings for the multicast socket options (notably, BSD/386). On the i386, we've added code to use the non-standard encodings by default, but revert to the standard encodings if this fails. This should solve the compatibility problems among BSD/386, NetBSD, and FreeBSD. Note that BSD/386 (and possibly the other BSD's) still lack the proper in_pcb.c. A kernel source patch for BSD/386 v1.1 is in ftp://ftp.ee.lbl.gov/INPCB-bsd386-v1.1-patch. The DEC Alpha binary is now built under OSF/1 v2.0. We haven't tried it out under v1.3 and would be surprised if it worked. Other major changes are listed below. Bugs, questions, and comments to vat@ee.lbl.gov. Steve & Van ----------- v3.3 Wed Jun 1 13:46:55 PDT 1994 - Another cut at release/hold button. Removed the "Release" button since idleHoldTime is now non-zero by default so that de-selecting the Keep button is the same as clicking the Release button. - Fixed LPC decoding on an SGI. - Added support for AudioFile on SparcStations and Indigos. Set Vat.useAF if you want to use AudioFile instead of the bare audio device. Vat.afDevice controls the AudioFile device number. -U allows you to specify AudioFile from the command line. If you give a number instead of a pathname, AudioFile is used with the device numer indicated. (The man page explains what -U with a pathname does.) - Added checks for 4.4BSD multicast IP options encodings. If the standard setsockopt's don't work, try the BSD numbers. This means that the i386 binary should work both on systems with the standard encodings as well as BSD/386 v1.1 and 4.4BSD. CSRG and BSDI changed the encodings to be keep binary compatibility with the IP options that were added in Net 2 (IP_HDRINCL, IP_TOS etc.). - DEC Alpha and DEC mips versions now linked against Release 3 AudioFile server. Vat will no longer work with the Release 2 server. - Fixed bug that allowed only one stat window per mixer, even when there were multiple sources behind the mixer (bug reported by David Comay). - Added backward compatibility for "idvi" format string, which is equivalent to "dvi". - Added button to enable/disable encryption, as opposed to typeing in an empty key to disable it. - Change default ttl from 127 to 16 so people who start vat manually don't pollute the world with their audio tests. - Tried to make audio access stuff (keep/release/etc.) work more reliably but was largely stymied by tk's totally broken event handling. - Keep track of incoming packet lengths so encoding doesn't flicker between pcm/pcm2/pcm4 when there's significant packet loss. (problem first reported by Mark Handley). From rem-conf-request@es.net Thu Jun 02 00:15:14 1994 Received: from oucsace.cs.ohiou.edu by osi-west.es.net via ESnet SMTP service id <03810-0@osi-west.es.net>; Wed, 1 Jun 1994 21:14:48 +0000 Received: (from dprince@localhost) by oucsace.cs.ohiou.edu (8.6.8/8.6.6) id AAA11901 for rem-conf@es.net; Thu, 2 Jun 1994 00:14:42 -0400 From: "David W. Prince" Message-Id: <199406020414.AAA11901@oucsace.cs.ohiou.edu> Subject: HHow do I UNsub from this? To: rem-conf@es.net Date: Thu, 2 Jun 1994 00:14:42 -0400 (EDT) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 75 How do I unsubscribe to this listserv? Thank you for your help. Jonathan From rem-conf-request@es.net Thu Jun 02 08:47:18 1994 Received: from uucp4.netcom.com by osi-west.es.net via ESnet SMTP service id <05037-0@osi-west.es.net>; Thu, 2 Jun 1994 05:46:56 +0000 Received: from nitelog.UUCP by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id FAA10414; Thu, 2 Jun 1994 05:41:46 -0700 Received: by nitelog (PCBuucp 2.0) with UUCP id D05678; Thu, 2 Jun 94 05:24:35 -0800 To: rem-conf@es.net Subject: Holography lecture is for real From: kim.cohan@nitelog.com (Kim Cohan) Message-ID: Date: Wed, 1 Jun 94 23:44:00 -0800 Organization: Nitelog BBS - Monterey, CA - 408-655-1096 SOme have asked me if the offer of popcorn is a joke- It is not. If you will be watching the lecture on fine art holography, (1930 PDT Sat 4 June thats 0230 UT Sun 5 June) we will send you the popsorn and the sticker. Kim From rem-conf-request@es.net Thu Jun 02 08:48:48 1994 Received: from uucp4.netcom.com by osi-west.es.net via ESnet SMTP service id <05047-0@osi-west.es.net>; Thu, 2 Jun 1994 05:48:22 +0000 Received: from nitelog.UUCP by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id FAA10551; Thu, 2 Jun 1994 05:43:42 -0700 Received: by nitelog (PCBuucp 2.0) with UUCP id D0567A; Thu, 2 Jun 94 05:24:36 -0800 To: rem-conf@es.net Subject: More prizes announced. Stickers on the way From: kim.cohan@nitelog.com (Kim Cohan) Message-ID: Date: Wed, 1 Jun 94 23:48:00 -0800 Organization: Nitelog BBS - Monterey, CA - 408-655-1096 THose who have requested stickers, and will be watching the Carl Cherry Center for the Arts holography lecture on MBONE this Saturday, 4 June at 1930 PDT will be receiving their stickers soon. * * * * * * * * * More Prizes * * * * * * * * * The first viewer from each country to email a question to the lecture hall will be sent a 4 x 5" hologram by Robert Hess. Plus, all email questioners will be eligible for a really cool space ship hologram. We really want lots of international co-operation! Kim From rem-conf-request@es.net Thu Jun 02 12:19:36 1994 Received: from mercury.unt.edu by osi-west.es.net via ESnet SMTP service id <05773-0@osi-west.es.net>; Thu, 2 Jun 1994 09:19:13 +0000 Received: from noc.unt.edu by mercury.unt.edu with SMTP id AA23663 (5.65c/IDA-1.4.4 for ); Thu, 2 Jun 1994 11:19:10 -0500 Received: (darren@localhost) by noc.unt.edu (8.6.8.1/8.6.4) id LAA14753; Thu, 2 Jun 1994 11:19:16 -0500 Date: Thu, 2 Jun 1994 11:19:15 -0500 (CDT) From: Darren Paul Loher Subject: Cisco's Multicast Support (fwd) To: rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From the cisco mailing list. ---------- Forwarded message ---------- Date: Wed, 1 Jun 1994 14:55:09 -0700 From: Dino Farinacci To: dad@zh014.ubs.ubs.ch Cc: cisco@spot.colorado.edu Subject: Cisco's Multicast Support >> Where can I go (what can I read) to figure out how Cisco's handle multicast'ing. ftp.cisco.com:/ftp/dino/pim* Dino From rem-conf-request@es.net Thu Jun 02 14:02:51 1994 Received: from piper.cs.colorado.edu by osi-west.es.net via ESnet SMTP service id <06089-0@osi-west.es.net>; Thu, 2 Jun 1994 11:02:24 +0000 Received: (from evi@localhost) by piper.cs.colorado.edu (8.6.9/8.6.9) id MAA09160; Thu, 2 Jun 1994 12:02:20 -0600 Date: Thu, 2 Jun 1994 12:02:20 -0600 From: Evi Nemeth Message-Id: <199406021802.MAA09160@piper.cs.colorado.edu> To: rem-conf@es.net Subject: USENIX Keynote, Final Session, MBONE Broadcast, Jun 8 9AM, Jun 10 3PM Cc: evi@piper.cs.colorado.edu The USENIX Conference in Boston, June 6-10, at the Copley Marriot will be celebrating the 25th anniversary of the UNIX operating system. We will be broadcasting the Keynote Address and the final session, a UNIX Jeopardy Game. More detailed descriptions follow; it will be listed in sd. Keynote Address, June 8, 9:15-10:30AM EDT (GMT+5) Penn Jillette of Penn & Teller "Who will be the Desi Arnaz of the Internet" We will be testing new releases of the videoconferencing software from LBL and Xerox PARC. The conference will monitor penn@usenix.org for comments on this experiment. Also, while speaking, Penn will scan that mailbox for anything that strikes his fancy. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Final Session, June 10, 3:30-5:00PM EDT (GMT+5) The final session of the conference will be three games of Jeopardy played by the winners of a trivia quiz on the history of the UNIX operating system followed by the Final Playoff and the naming of the Universe U-Word Jeopardy Master! The trivia quiz will be completed by contestants during the conference; we will post it Thursday evening, June 9 after the qualifying round is completed. Judges include Dennis Ritchie, Bill Shannon and Kirk McKusick; MC is Rob Kolstad. From rem-conf-request@es.net Thu Jun 02 14:24:58 1994 Received: from uucp2-b.netcom.com by osi-west.es.net via ESnet SMTP service id <06152-0@osi-west.es.net>; Thu, 2 Jun 1994 11:24:30 +0000 Received: from nitelog.UUCP by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id LAA27969; Thu, 2 Jun 1994 11:16:06 -0700 Received: by nitelog (PCBuucp 2.0) with UUCP id D05687; Thu, 2 Jun 94 11:01:07 -0800 To: rem-conf@es.net Subject: 40 viewers to watch holography lecture From: kim.cohan@nitelog.com (Kim Cohan) Message-ID: Date: Thu, 2 Jun 94 06:49:00 -0800 Organization: Nitelog BBS - Monterey, CA - 408-655-1096 At least 40 sites around the world will be watching the Carl Cherry Center for the Arts holography lecture this coming saturday. We still haven't heard from Japan, Asia, or SOuth America. Lets make this a worldwide event! The first viewer from each country to email in a question will receieve a neat 4x5" hologram plate made by Bob Hess. * * * * * * * * Original Announcement follows: TO: MBONE video viewers NOTE: If you watch: Email me for a free hologram sticker and a packet of microwave popcorn. This MBONE show is one that we encourage you to invite your friends to watch along with you. Invite artists as well. Show your friends what the internet is all about. On Saturday, June 4th at 7:30PM PDST ( thats Sun. 5 June, 02:30GMT) The Carl Cherry Center for the Arts, Carmel (Ca), will broadcast on MBONE, an fascinating program on fine art holography. Tune in to see & hear live: A hologram being made Neat video of the fine art holograms in our gallery A panel discussion by holography artists A lecture by Dr. Tung Jeong, an expert of display holography You can email or chat questions in realtime to us in the lecture hall during the question and answer period. (We will announce details on email or chat address before the lecture). To make it fun to watch, this program will be shot using professional camera and sound operators. To keep things interesting, we will cut to dynamic images of the 25 fine art holograms on display in our gallery. This program airs on a Saturday, so make it a special occasion to watch. Impress your significant other- make a date of it! We can't think of anything more fun, romantic, or educational than watching our upcoming MBONE program about fine art holograms. In his lecture, "The Photonic Revolution", Dr. Tung Jeong, Lake Forest College (IL) will explain what a hologram is, and will make one right on stage. Dr. Jeong delivers an entertaining and lively lecture. He is chairman of the Photonics department at Lake Forest College (IL), and is the winner of the Millikan Award for Excellence in Teaching. He is a member of SPIE, and a fellow of the Optics Society. He is Director of the International Symposia on Display Holography. Our visiting artists include: Fred Unterseher, formerly of the Exploratorium, and the Holography Museum of New York, and author of the 50,000 copy selling Holography Handbook. Anait, the first holographer to show fine art holograms. And John Kaufman, creator of "After the Reaper" a moving war memorial to his father, a WWII veteran. Following the lecture, our seven visiting artists will take the stage and present a round-table discussion on the subject of "Is it Art Yet?". They will share their experiences as artists struggling to get recognition from the art establishment for the new art of holography. During both segments, Dr. Jeong and the artists will answer questions you email or chat to us at the lecture hall. Email me to let me know if you are interested in watching, and to order your free viewers kit including your own hologram sticker and a package of microwave popcorn. Win a real hologram: To encourage viewers to participate, anyone sending us a question during the lecture will be eligible for a drawing for a really neat 4"x5" hologram of the space shuttle by Bob Hess of Boulder Creek, CA. The Carl Cherry Center for the Arts is a 501(c)3 non profit art museum in Carmel Ca. It is really neat for a small organization like ours (1 paid staff person), to be able to present this lecture on the internet. It's what the internet is all about! Kim Cohan (408) 659-5691voice (408) 659-5691 fax kim.cohan@nitelog.com and please copy to: kcohan@mpusd.k12.ca.us P.S. To find out if your campus is set up to receive MBONE video (video on a Sun, SGI, or Mac, workstation), ask your network coordinator, or email me and I'll try to find out. From rem-conf-request@es.net Fri Jun 03 15:55:07 1994 Received: from nps.navy.mil by osi-west.es.net via ESnet SMTP service id <10895-0@osi-west.es.net>; Fri, 3 Jun 1994 12:54:47 +0000 Received: from merak.cc.nps.navy.mil by nps.navy.mil (4.1/SMI-4.1) id AA17006; Fri, 3 Jun 94 12:54:00 PDT Received: by merak.cc.nps.navy.mil (920330.SGI/931108.SGI.ANONFTP) for @nps.navy.mil:mbone@isi.edu id AA05141; Fri, 3 Jun 94 12:55:50 -0700 Date: Fri, 3 Jun 94 12:55:50 -0700 From: mccann@nps.navy.mil (Mike McCann) Message-Id: <9406031955.AA05141@merak.cc.nps.navy.mil> To: rem-conf@es.net, mbone@isi.edu Subject: Holography lecture info Cc: kim.cohan@nitelog.com Final preparations are being made for the holography lecture originating from Carmel, California USA. The lecture begins on Saturday, June 4th at 7:30PM PDT (USA) (Sun. 5 June, 02:30 UT). The "Art of the Hologram" session is now advertised in 'sd'. vat audio is at Addr: 224.2.224.125 Port: 49597 ID: 51729 TTL: 127 nv video is at Addr: 224.2.224.125 Port: 36069 TTL:127 For more info (actually the collection of e-mail postings to rem-conf) point your www client program (e.g. mosaic) to: http://www.nps.navy.mil/VisLab/holo.html We are encouraging questions over the vat audio connection as well as via e-mail. Send your e-mail questions for the presenters to the following address: srbible@nps.navy.mil The vat audio will not play in the auditorium, so when we ask for questions from the net feel free to talk as your question will be relayed via telephone to the presenters. As described in earlier postings, first questioners from each country will receive special prizes (no joke!). We will begin testing the audio and video links approximately 24 hours from now. Please join the session early so that we may announce to the audience how far reaching this lecture and the MBone is. You can also help us with debugging (if needed). Regards, Mike (for Kim Cohan of the Carl Cherry Center for the Arts) P.S. Does anyone have a point of contact for the Antarctica MBone recipients? We would love to have someone from that continent watch. ------------------------- Mike McCann Naval Postgraduate School (mccann@nps.navy.mil) Vis Lab, Code 51 (In-102b) Monterey, CA 93943 (408) 656-2752 From rem-conf-request@es.net Fri Jun 03 22:07:55 1994 Received: from rigel.infinet.com by osi-west.es.net via ESnet SMTP service id <11678-0@osi-west.es.net>; Fri, 3 Jun 1994 19:07:31 +0000 Received: from nitelog by mail.infinet.com with uucp (Smail3.1.28.1 #9) id m0q9lBK-000DLZC; Fri, 3 Jun 94 22:09 EDT Received: by nitelog (PCBuucp 2.0) with UUCP id D04F4A; Fri, 3 Jun 94 19:00:31 -0800 To: rem-conf@es.net Subject: Holography lecture ip & EMAIL info. From: kim.cohan@nitelog.com (Kim Cohan) Message-ID: Date: Fri, 3 Jun 94 18:58:00 -0800 Organization: Nitelog BBS - Monterey, CA - 408-655-1096 Thanks so much to all those agreeing to watch the lecture. Here's important information about "The Art of the Hologram" lecture: Please log in a few minutes early so that we can announce your presence to our theater audience. It airs at 1930 PDT (California, USA) Sataurday evening, June 4. I think that is 0230 Greenwich Mean Time GMT, UT, zulu, etc. Send email to: srbible@nps.navy.mil (Steve Bible) * * * * * * * Send us Email & Win a prize! * * * * * * Remember, the first person to send in a question from each country will receive a neat 4"x5" hologram of a space ship. Steve will be sitting at the back of the theater and every time one of your emailed questions comes in, he will rush it up to the stage. Lets give Steve lots of exercize!!! Your stickers and popcorn were sent. If you haven't gotten them yet, be patient (snail mail and all that). The "Art of the Hologram" session is now advertised in 'sd'. vat audio is at Addr: 224.2.224.125 Port: 49597 ID: 51729 TTL: 127 nv video is at Addr: 224.2.224.125 Port: 36069 TTL:127 I hope you all will enjoy our broadcast. Kim Cohan kim.cohan@nitelog.com 408-624-7491 From rem-conf-request@es.net Sat Jun 04 23:04:29 1994 Received: from upeksa.sdsc.edu by osi-west.es.net via ESnet SMTP service id <14025-0@osi-west.es.net>; Sat, 4 Jun 1994 20:04:00 +0000 Received: by upeksa.sdsc.edu id AA11517; Sat, 4 Jun 1994 20:03:50 -0700 From: kc@upeksa.sdsc.edu (k claffy) Message-Id: <9406050303.AA11517@upeksa.sdsc.edu> Subject: holography lecture transmission quality? To: mccann@nps.navy.mil (Mike McCann) Date: Sat, 4 Jun 94 20:03:49 PDT= Cc: rem-conf@es.net, srbible@nps.navy.mil, kim.cohan@nitelog.com In-Reply-To: <9406031955.AA05141@merak.cc.nps.navy.mil>; from "Mike McCann" at Jun 3, 94 12:55 pm uh, has anyone given feedback on the quality of this video/audio -- i can't make out either one -- k From rem-conf-request@es.net Sun Jun 05 00:37:32 1994 Received: from hub.ubc.ca by osi-west.es.net via ESnet SMTP service id <14124-0@osi-west.es.net>; Sat, 4 Jun 1994 21:36:59 +0000 Received: by hub.ubc.ca (4.1/1.14) id AA10129; Sat, 4 Jun 94 21:36:51 PDT Date: 4 Jun 94 21:36 -0700 From: Marilyn Martin To: "(Mike McCann)" Cc: rem-conf@es.net, srbible@nps.navy.mil, kim.cohan@nitelog.com, kc@upeksa.sdsc.edu In-Reply-To: <9406050303.AA11517(a)upeksa.sdsc.edu> Message-Id: <35077*martin@ucs.ubc.ca> Subject: holography lecture transmission quality? The speaker is moving a lot and so the video is very chopped up. This made most of the audio very sporadic and difficult to understand. The audio came through well when the slides were being shown. Thanks for all your efforts. Marilyn Martin voice mail: 604-822-5438 Network Management Centre fax mail: 604-822-5116 University of British Columbia e-mail: Marilyn.Martin@ubc.ca Vancouver, B.C. Canada V6T 1Z2 From rem-conf-request@es.net Sun Jun 05 00:51:31 1994 Received: from hub.ubc.ca by osi-west.es.net via ESnet SMTP service id <14146-0@osi-west.es.net>; Sat, 4 Jun 1994 21:50:52 +0000 Received: by hub.ubc.ca (4.1/1.14) id AA10278; Sat, 4 Jun 94 21:50:45 PDT Date: 4 Jun 94 21:50 -0700 From: Marilyn Martin To: srbible@nps.navy.mil, rem-conf@es.net Message-Id: <35078*martin@ucs.ubc.ca> Subject: Re: holography lecture transmission quality? The musical interludes come across fine :) From rem-conf-request@es.net Sun Jun 05 08:56:09 1994 Received: from uni-sb.de by osi-west.es.net via ESnet SMTP service id <15233-0@osi-west.es.net>; Sun, 5 Jun 1994 05:55:47 +0000 Received: from com-serv.dfki.uni-sb.de with SMTP by uni-sb.de (5.65++/UniSB-2.2/940526) id AA13920; Sun, 5 Jun 94 14:55:40 +0200 Received: from wip-sol.dfki.uni-sb.de by com-serv.dfki.uni-sb.de id AA02798; Sun, 5 Jun 94 13:06:06 +0200 Organization: DFKI Saarbruecken GmbH, D-66123 Saarbruecken (Germany) Received: by wip-sol.dfki.uni-sb.de with SMTP; Sun, 5 Jun 94 13:07:29 +0200 From: Wladimir Minenko Date: Sun, 5 Jun 94 13:07:20 +0200 Message-Id: <9406051107.AA00932@kik-11> Received: by kik-11; Sun, 5 Jun 94 13:07:20 +0200 To: mbone@ISI.EDU, rem-conf@es.net Subject: Application Sharing in MBone Cc: jean@dfki.uni-sb.de, mweber@dfki.uni-sb.de, wr@dfki.uni-sb.de Hi MBone Community! I'm a new member in the MBone world and I have only a very little experience in the network engineering, but I've already read some articles, browsed News, WWW and FAQ. I've found the ideas of Mbone VERY very interesting and directly had some ideas how to apply the MBone technology in order to implement some new MBone tools which can significant extend its functional features. I'm working on different issues of the application sharing under X Window. The first steps in this area I have done for about 3 years. Before this time I've developed an X Window recorder (it was my first X application), where one can record an X session and then play back it by broadcasting to single or numerous displays. Currently I have an stable version of the application sharing system (called "xplexer") which runs on different UNIX systems and is tested in various test installations. xplexer shows much better results as known (for me) PD tools (shX, XTV, xmx) and some other not PD tools.xplexer is the application sharing system based on intercepting of the X protocol by collecting events and broadcasting requests to numerous destinations. xplexer allows you dynamically add/remove participant to/from the session, pass the token and point something with a telepointer. xplexer runs with X11R4 till X11R6 (a "normal" MIT server, a 24-bit server, a server with video, xnews-server) under SunOS 4.1.x, IRIX 4.0.5, IRIX 5.1, SCO ODT 3.0, System V R4, Linux 1.0 and in the next time under Solaris 2.x. As participants' displays are tested in extension to mentioned systems: DEC Alfa with OSF/1, HP900, IBM RS6000, MS-Windows: PC-Xware, HCL/Exceed, X-Vision. The favorite test applications are FrameMaker, Island-Tools (Sun), WABI, DOS/Windows-Merge and a CAD-package. Currently, I work on the system further and keep a look on other (known for me) application sharing tools. Intensive work on performance design issues has allowed to reach only 5% performance loss (tested with xbench) if you start a application via xplexer. Unfortunately with each new participant you lose about 10% of the application performance. The solution is to extend xplexer allowing to run "sometimes" in a distributed architecture by connecting numerous xplexers running by each session participant. There are already some design ideas and implementation tests. THE PROBLEM IS that such a system runs via TCP/IP socket: the same X request is sent multiple over the network. I think that a multicast based protocol (such as RTP) is a perfect solution for the problem. I estimate that with multicast it will be possible to have not much more then 5% performance loss INDEPENDENT on the number of the session participants! Since you all have much more experience with multicast services, I'd like to ask you to help me to begin my work in this area. What I need is INFORMATION. I'd like to know/have: 1. Are there any communication libraries which can be used as multicast interface? I need reliable, possibly bidirectional connections; 2. Is RTP available as a library or as a well commented example? 3. Is there (or will be one) implementation of multicast based on TCP? 4. Is there somebody who has a idea to implement application sharing for MBone? I will be very happy if you can give me any advice! If you know somebody who can help me, please forward this message! Thank you very much in advance -- Regards Wladimir Minenko Project TEAMKOM DFKI GmbH ===> German Research Center for Stuhlsatzenhausweg 3 Artificial Intelligence Inc. 66123 Saarbruecken Germany Tel. +49-681-302-5294 Fax. +49-681-302-5297 e-mail: minenko@dfki.uni-sb.de ******************************************************** Disclaimer: The contents of this message in no way reflects the opinions either real or imaginary of the DFKI GmbH or Siemens AG. All opinions/rantings are my own and only I am responsible for them. ******************************************************** From rem-conf-request@es.net Sun Jun 05 09:20:14 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <15257-0@osi-west.es.net>; Sun, 5 Jun 1994 06:19:46 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 5 Jun 1994 14:19:00 +0100 To: Wladimir Minenko cc: mbone@ISI.EDU, rem-conf@es.net, jean@dfki.uni-sb.de, mweber@dfki.uni-sb.de, wr@dfki.uni-sb.de Subject: Re: Application Sharing in MBone In-reply-to: Your message of "Sun, 05 Jun 94 13:07:20 +0100." <9406051107.AA00932@kik-11> Date: Sun, 05 Jun 94 14:18:55 +0100 From: Jon Crowcroft multicast X would be handy. In particluar, assuming your model is strictyly seminar like as opposed to conference like, yo uare guaranteed to have a 'Shared X' model of floor contro l(i.e. only one controlling tty/ keyboard/mouse at once) thje way i'd implement things then is not to use RTP at all i'd have a TCP connection from the controlling terminal to the application (i.e. standard X, ) and multicast the data for other applications, and then design a distributed repair protocol for missing bits (c.f. Van's whiteboard) how to hide this so the X servers think they are all just getting data from a relaible stream? tricky....also, you need to have the X server to receive UDP (i.e. remove a few lines of socket code..., or add some for the new type of X data...) >1. Are there any communication libraries which can be used as multicast > interface? I need reliable, possibly bidirectional connections; CCCP from mark handley & ian wakeman may do what you want here... see cs.ucl.ac.uk:mice/cccp_slides/cccp_slides.tar >2. Is RTP available as a library or as a well commented example? i'll leave this to steve casner et al.. >3. Is there (or will be one) implementation of multicast based on TCP? no - its not really a brilliant idea...see cs.ucl.ac.uk:darpa/tcp-multicast.lp for how to do it though... >4. Is there somebody who has a idea to implement application sharing for MBone? yes - van - see wb! if you are thinking about large scale, and multiple users' input, and dynamic membership, then the approach in wb is very nice... cheers jon From rem-conf-request@es.net Sun Jun 05 12:25:24 1994 Received: from gaia.electrum.kth.se by osi-west.es.net via ESnet SMTP service id <15446-0@osi-west.es.net>; Sun, 5 Jun 1994 09:25:05 +0000 Received: from localhost.electrum.kth.se by gaia.electrum.kth.se (5.61-bind 1.4+ida/4.0) id AA01487; Sun, 5 Jun 94 18:24:54 +0200 Message-Id: <9406051624.AA01487@gaia.electrum.kth.se> To: mbone@isi.edu, rem-conf@es.net Subject: Proposal of new Usenet-group for mmconferencing... Date: Sun, 05 Jun 94 18:24:53 +0200 From: Christian Wettergren Hi! My name is Christian Wettergren, and I'm working in the MICE National Support Center (for Sweden). We're proposing that a Usenet group for the multicasting video conferencing tools be set up. This posting is meant to start a discussion about the scope and charter for such a group. Background: ----------- What is MICE? MICE stands for "Multimedia Conferencing in Europe", and is a Esprit financed research project investigating feasability of videoconferencing, and trying to locate problem areas. (For further information, please contact the MICE NSC:s. Since they are not up and running yet, you may contact me in the mean time, and I'll forward your request to the appropriate people. You could however try the URL http://www.cs.ucl.ac.uk/mice/mice-nsc/index.html for the MICE-NSC England.) MICE is using multicasting tools developed by others, and those currently used are 'sd', 'vat', 'ivs', 'wb' and occasionally 'nv'. They all run on the MBone. (By MICE tools, we of course don't mean that we wrote them, but rather that we are using them. This is only a convenience term for us.) The MICE project has decided to set up MICE National Support Centers, whose mission is to promote the use of the MICE tools and video conferences. These centers are national, and should promote MICE tools within that country. The MICE NSCs will also help setting up new NSCs, provided there is funding from within that country. (For further information see URL http://www.cs.ucl.ac.uk/mice/mice-nsc/charter.html) The newsgroup: -------------- During a recent MICE meeting we discussed user support for these tools. We came to the conclusion that a Usenet group could be an effective complement to the MICE NSCs. I make the following proposal of scope and charter. This is not an official CFD, this is merely a pre-CFD discussion. Any input is welcomed! I suggest that the group should be called 'comp.multimedia.mice'. Other suggestions have been 'eunet.mice-users', but that was scrapped since non-Europe sites usually doesn't carry these groups, and that would be counterproductive. We would like to have the name MICE somewhere in the groupname of funding reasons, and also since the MICE NSCs will actively help people out in this group. The scope of the group should be discussions about the multicasting conferencing tools, their use and experiences with them. It will inevitably carry some newcomer's questions. Some of these should be possible to direct to FAQs. Some discussion about multicasting will also take place there too, but the bulk of it should stay on the mbone-list. I also think that the rem-conf list still should have the role of a "reservation channel", where the MBone booking should be performed. At the same time, announcements should probably be crossposted to the mice-users group as well. The MICE NSCs will actively try to help people out when they have questions. One complication is that since MICE is a european project with nationally financed centers, we may limit the time spent answering questions from "unsupported" areas. This will most probably not become a problem, but it should be mentioned so that no misunderstanding will arise. The group should be unmoderated. But at the same time, the MICE NSCs will have some kind of unofficial hosting role, helping people out, and develop FAQs and so on. The MICE NSCs would like to connect this group to some local mailing lists, set up at the national level. This is so that sites which dont have Usenet can participate. Other possible groups --------------------- I have looked around in Usenet, and not found anything treating this subject. There is one group called rec.video.desktop, but it aims mainly at Macintosh, CDROM and QuickTime etc. Our group is instead aiming at H.261, multicasting and MBone. I have posted proposal in that group about including our stuff in they're group, but there wasn't any reactions (except for a couple of inquiries about MICE). The current situation is that people discuss these things on the mbone list and the rem-conf list. Unfortunately, not many novices know about these lists, and hence cannot get appropriate help. How to continue --------------- Lets discuss this, and come up with a reasonable Call For Discussion proposal. I suspect there are some opinions out there. :-) I will send this to the mbone@isi.edu, rem-conf@es.net and also post it to Usenet rec.video.desktop and some other groups, like comp.multimedia. This document has been circulated internally within the MICE NSCs prior to this release. If you want, I can collect the various suggestions and revise a charter. I suggest you send submissions to me, unless someone have strong opinions about it. Regards, Christian Wettergren, KTH/Teleinformatics, cwe@it.kth.se for the MICE NSCs. From rem-conf-request@es.net Sun Jun 05 13:26:28 1994 Received: from mail.cs.tu-berlin.de by osi-west.es.net via ESnet SMTP service id <15490-0@osi-west.es.net>; Sun, 5 Jun 1994 10:26:07 +0000 Received: from kubismus.cs.tu-berlin.de (cabo@kubismus.cs.tu-berlin.de [130.149.25.94]) by mail.cs.tu-berlin.de (8.6.9/8.6.9) with ESMTP id TAA07348; Sun, 5 Jun 1994 19:24:57 +0200 Received: (cabo@localhost) by kubismus.cs.tu-berlin.de (8.6.7/8.6.6) id TAA04687; Sun, 5 Jun 1994 19:24:53 +0200 Date: Sun, 5 Jun 1994 19:24:53 +0200 Message-Id: <199406051724.TAA04687@kubismus.cs.tu-berlin.de> To: J.Crowcroft@cs.ucl.ac.uk CC: wladimir@dfki.uni-sb.de, mbone@ISI.EDU, rem-conf@es.net, jean@dfki.uni-sb.de, mweber@dfki.uni-sb.de, wr@dfki.uni-sb.de, torsten@prz.tu-berlin.de, nilss@cs.tu-berlin.de, hcg@cs.tu-berlin.de, gh@prz.tu-berlin.de, jo@cs.tu-berlin.de From: cabo@informatik.uni-bremen.de In-reply-to: <199406051429.QAA15768@mail.cs.tu-berlin.de> (message from Jon Crowcroft on Sun, 05 Jun 94 14:18:55 +0100) Subject: Multicast X (Re: Application Sharing in MBone) > Date: Sun, 05 Jun 94 14:18:55 +0100 > From: Jon Crowcroft > > multicast X would be handy. Right. That's why we built it. %A Carsten Bormann %A Gero Hoffmann %T Xmc and Xy \*- Scalable Window Sharing and Mobility, or, From X Protocol Multiplexing to X Protocol Multicasting, %R Proceedings of the 8th X Technical Conference %J The X Resource %V 9 %D January 1994 The basic idea is to interpose an Xy server and an Xy agent between an application and the X displays of various participants, where the Xy server simulates an X server to the application and generates X multicast (Xmc) protocol data, which is received by the Xy agents and forwarded to the target X servers. We are right now frantically working for the X11R6 contrib deadline, therefore we won't be able to be very responsive to E-mail for some time. For actually multicasting the Xmc protocol data, we use IP multicast and our own rendition of MTP (RFC 1301), see: %A Carsten Bormann %A Joerg Ott %A Gero Hoffmann %T First Experience with Multicasting the X Protocol %B Broadband Islands Third International Conference %I Elsevier %D 1994 While we do have MTP up and running (and hope to put this on X11R6 contrib), we are working on fixing up MTP to be more applicable to larger groups. I'm just finishing up a forthcoming article: %A Carsten Bormann %A Joerg Ott %A Hans-Christian Gehrcke %A Torsten Kerschat %A Nils Seifert %T MTP-2: Towards Achieving the S.E.R.O. Properties for Multicast Transport %R submitted for publication (S.E.R.O. ist Scalability, Efficiency, Robustness, Ordering.) If anyone thinks this is useful work, we might consider setting up a reliable multicast transport protocol BOF at the July IETF. Gruesse, Carsten From rem-conf-request@es.net Sun Jun 05 22:36:00 1994 Received: from gallery.ncb.gov.sg by osi-west.es.net via ESnet SMTP service id <15916-0@osi-west.es.net>; Sun, 5 Jun 1994 19:35:26 +0000 Received: by ncb.gov.sg (4.1/SMI-4.1) id AA07826; Mon, 6 Jun 94 10:38:09 SST Date: Mon, 6 Jun 1994 10:35:55 +0800 (SST) From: Tan Pow Hwee Subject: mrouted/source routing To: rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I vaguely recall there are discussions here some time ago about a version of mrouted that does not use source routing. Does such a version exist already? Where can I get it? Thanks for any pointers. Regards, Pow-hwee Tan From rem-conf-request@es.net Mon Jun 06 00:02:34 1994 Received: from sangam.ncst.ernet.in by osi-west.es.net via ESnet SMTP service id <16039-0@osi-west.es.net>; Sun, 5 Jun 1994 21:02:03 +0000 Received: (from uucp@localhost) by sangam.ncst.ernet.in (8.6.8.1/8.6.6) with UUCP id JAA08260; Mon, 6 Jun 1994 09:29:18 +0530 Received: by henna.iitd.ernet.in (4.1/SMI-4.1-MHS-7.0 ) id AA00818; Mon, 6 Jun 94 09:23:25 IST X-Organisation: Indian Institute of Technology, New Delhi. Date: Mon, 6 Jun 1994 09:12:25 +0530 (IST) From: Palepu Srinivas Subject: Re: Multicast X (Re: Application Sharing in MBone) To: cabo@informatik.uni-bremen.de Cc: J.Crowcroft@cs.ucl.ac.uk, wladimir@dfki.uni-sb.de, mbone@ISI.EDU, rem-conf@es.net, jean@dfki.uni-sb.de, mweber@dfki.uni-sb.de, wr@dfki.uni-sb.de, torsten@prz.tu-berlin.de, nilss@cs.tu-berlin.de, hcg@cs.tu-berlin.de, gh@prz.tu-berlin.de, jo@cs.tu-berlin.de In-Reply-To: <199406051724.TAA04687@kubismus.cs.tu-berlin.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > (S.E.R.O. ist Scalability, Efficiency, Robustness, Ordering.) > > If anyone thinks this is useful work, we might consider setting up a > reliable multicast transport protocol BOF at the July IETF. > > Gruesse, Carsten I think there is a great need for this. There are several groups in the internet community, which are working on this. Perhaps, if some heads can be put together to frame a draft for a reliable multicast transport protocol, it might be better than everybody doing it in isolation. Such a protocol is extremely important, and will definitely help in promoting a multicast environment where more applications can be thought of and reliable interactivity also can be increased. I strongly advocate setting up of such a forum ASAP. ============================================================================= Srinivas Palepu palepu@henna.iitd.ernet.in Ph: (W) +91-11-686 7431 Deptt of Comp.Sc & Engg Voice Mail +91-11-376 0520 IIT Hauz Khas, N.Delhi-16 Fax +91-11-686 8765 ----------------------------------------------------------------------------- From rem-conf-request@es.net Mon Jun 06 12:40:03 1994 Received: from diable.upc.es by osi-west.es.net via ESnet SMTP service id <21663-0@osi-west.es.net>; Mon, 6 Jun 1994 09:39:40 +0000 Received: by diable.upc.es (4.1/SMI-4.1) id AA02522; Mon, 6 Jun 94 18:39:36 +0200 Date: 6 Jun 94 18:39 +0200 From: "Manuel A. Marin" To: rem-conf@es.net Message-Id: <244*M.Marin@si.upc.es> Subject: NV, bit experience Hi, my name is Manuel Marin and I'm network and system manager at the Politechnic University of Catalonia (UPC). Last week, I made a bit experience with videoconference. I explain you, in the context of ULPAA'94 congress (Upper Layer Protocols, Architectures and Applications) organaized by IFIP at the UPC, I conected two conferences rooms (the master and the secondary). During the congress every events in the master room were transmited to the secondary room via a videoconference system. Technical description: - The rooms were connected with a fiber optic cable running Ethernet protocol. - At each ends were connected two Indy Silicon Graphics with Irix 5.2 oper. syst. - It was used NV 5.2 for video and VAT for audio. - To Indys were connected two profesional cameras and the Indys sound systems were connected to the audio system in the rooms. - In the secondary room, the Indy was connected to a Barco video projector. Result of the experiment: Globaly the experiment was very interesting. In each rooms, the image and the sound were received with high quality. Only some details: - If we select the "silence supress" option in VAT then the voice doesn't listen very well, this because there was too much noise and VAT stop the transmition. It believe there is silence. - NV 5.2 is limited at 1 Mbyte. This is a problem because doesn't transmit all the information required to obtain quality enough. NV should transmit at 2 Mbits or 25 frames per second in order to obtain good quality. - Every operations are made by soft (compression, uncompression, etc) will be good idea to use the video card facilities. - Finally, there was some problems with speekers because they didn't write slices in order to transmit via a videoconference system. The slices had too many characters. Best regards, From rem-conf-request@es.net Mon Jun 06 13:16:36 1994 Received: from relay.nswc.navy.mil by osi-west.es.net via ESnet SMTP service id <21781-0@osi-west.es.net>; Mon, 6 Jun 1994 10:16:08 +0000 Received: from sunoco.nswc.navy.mil by relay.nswc.navy.mil (4.1/SMI-4.1) id AA27985; Mon, 6 Jun 94 13:15:58 EDT Received: from vaxless.b35ita.sunoco by sunoco.nswc.navy.mil (5.0/SMI-SVR4) id AA00943; Mon, 6 Jun 1994 13:16:03 +0500 Received: by vaxless.b35ita.sunoco (5.0/SMI-SVR4) id AA02095; Mon, 6 Jun 1994 13:16:01 +0500 Date: Mon, 6 Jun 1994 13:16:01 +0500 From: pirey%sunoco@relay.nswc.navy.mil (Phil Irey) Message-Id: <9406061716.AA02095@vaxless.b35ita.sunoco> To: rem-conf@es.net Subject: Mbone tools for PCs running Solaris? X-Sun-Charset: US-ASCII Content-Length: 104 Have any of the mbone tools (vat, wb, nv, etc.) have been ported to PCs running Solaris? thanks, phil From rem-conf-request@es.net Mon Jun 06 13:39:02 1994 Received: from NS.METROLINK.COM by osi-west.es.net via ESnet SMTP service id <21947-0@osi-west.es.net>; Mon, 6 Jun 1994 10:38:30 +0000 Received: from anubis.metrolink.com. (anubis.metrolink.com) by ns.metrolink.com with SMTP id AA23999 (5.67b/IDA-1.5 for ); Mon, 6 Jun 1994 13:38:27 -0400 Received: by anubis.metrolink.com. (4.1/SMI-4.1) id AA07623; Mon, 6 Jun 94 13:41:08 EDT Date: Mon, 6 Jun 94 13:41:08 EDT From: pax@anubis.metrolink.com (Garry M. Paxinos) Message-Id: <9406061741.AA07623@anubis.metrolink.com.> To: pirey%sunoco@relay.nswc.navy.mil, rem-conf@es.net Subject: Re: Mbone tools for PCs running Solaris? X-Mailer: XALT Mail [Version 1.1.a] X-Stamp-Id: 7 Priority: Medium > Have any of the mbone tools (vat, wb, nv, etc.) have been > ported to PCs running Solaris? If not, I am interested/willing/able to do the port.... Pax. ---- Metro Link Incorporated. 4711 N. Powerline Rd. Fort Lauderdale Fl, 33309 Voice: +1.305.938.0283x402 Fax: +1.305.938.1982 Email: pax@metrolink.com URL: http://ftlsig.metrolink.com/people/garryp.html "The real voyage of discovery consists not in seeking new landscapes but in having new eyes." -Proust From rem-conf-request@es.net Mon Jun 06 15:58:26 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <23069-0@osi-west.es.net>; Mon, 6 Jun 1994 12:57:59 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14506(2)>; Mon, 6 Jun 1994 12:57:46 PDT Received: from localhost by ecco.parc.xerox.com with SMTP id <16150>; Mon, 6 Jun 1994 12:57:41 -0700 To: pax@anubis.metrolink.com (Garry M. Paxinos) cc: rem-conf@es.net Subject: Re: Mbone tools for PCs running Solaris? In-reply-to: Your message of "Mon, 06 Jun 94 10:41:08 PDT." <94Jun6.113351pdt.14432(1)@alpha.xerox.com> X-Mailer: exmh version 1.4dilbert 6/3/94 Date: Mon, 6 Jun 1994 12:57:30 PDT Sender: Ron Frederick From: Ron Frederick Message-Id: <94Jun6.125741pdt.16150@ecco.parc.xerox.com> In message <94Jun6.113351pdt.14432(1)@alpha.xerox.com> you write: >> Have any of the mbone tools (vat, wb, nv, etc.) have been >> ported to PCs running Solaris? > > If not, I am interested/willing/able to do the port.... > I would expect nv to "just work", to at least the same extent that it works on Solaris 2.x for SPARCs. I don't know what video hardware you'd use, though. You may only be able to run it receive-only (or transmitting X11 screen shots) right now. If you've got a PC running Solaris and would like to try it, send me a note and I'll point you at the current 3.3alpha sources. In advance, you might want to pick up Tk 3.6 and Tcl 7.3 from sprite.berkeley.edu. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Mon Jun 06 16:15:46 1994 Received: from mailsun.aber.ac.uk by osi-west.es.net via ESnet SMTP service id <24181-0@osi-west.es.net>; Mon, 6 Jun 1994 13:15:14 +0000 Received: from athene.dcs.aber.ac.uk by mailsun.aber.ac.uk with SMTP (PP); Mon, 6 Jun 1994 21:14:17 +0100 Received: from thor.dcs.aber.ac.uk (thorbb) by athene.dcs.aber.ac.uk (4.1/aberclient-4.0-cs-1.1) id AA03459; Mon, 6 Jun 94 21:13:29 BST Received: from by thor.dcs.aber.ac.uk; Mon, 6 Jun 94 21:14:05 BST Message-Id: <22452.9406062014@thor.dcs.aber.ac.uk> X-Sender: dap@mailsun.aber.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 06 Jun 1994 19:56:04 +0100 To: rem-conf@es.net From: dap@aber.ac.uk (Dave Price at Home) Subject: Advice on choosing multicast addresses and Port numbers Cc: dap@aber.ac.uk X-Mailer: Dear All, Firstly, this email is from a new comer to this list so please make the usual fogiven for stupidities etc..... We are currently investigating/ building a prototype of a system to evaluate the potential of providing a `learning on demand' service where students can request reruns of lectures, or hold seminars/tutorials over the net. We are using NV, VAT, WB etc. We are not (yet) coupled to the MBONE, so my traffic will not effect the world (and vice versa), but even so, what algorithms do people use / should I use to choose multicast addresses / port numbers for the multiple sessions I may have in progress? Thanks for any advice, Dave Price Dave Price, Computer Science, University of Wales, Aberystwyth Email: dap@aber.ac.uk Tel: +44 970 622428 Fax: +44 970 622455 From rem-conf-request@es.net Mon Jun 06 16:21:53 1994 Received: from gatech.edu by osi-west.es.net via ESnet SMTP service id <22637-0@osi-west.es.net>; Mon, 6 Jun 1994 12:14:14 +0000 Received: from armani.gatech.edu by gatech.edu with SMTP id AA01342 (5.65c/Gatech-10.0-IDA); Mon, 6 Jun 1994 15:14:14 -0400 Received: by armani.gatech.edu (4.1/SMI-4.1) id AA27049; Mon, 6 Jun 94 15:19:15 EDT Date: Mon, 6 Jun 94 15:19:15 EDT From: ian@armani.gatech.edu (Ian F. Akyildiz) Message-Id: <9406061919.AA27049@armani.gatech.edu> To: cost237-transport@comp.lancs.ac.uk, end2end-interest@isi.edu, f-troup@aurora.cis.upenn.edu, hipparch@sophia.inria.fr, rem-conf-request@es.net, rem-conf@es.net, reres@laas.fr, sigmedia@bellcore.com, sound@acm.org, xtp-relay@cs.concordia.ca Subject: WORKSHOP_ANNOUNCEMENT CALL FOR PARTICIPANTS AND ANNOUNCEMENT Ninth Annual Workshop on COMPUTER COMMUNICATIONS Hawk's Cay Resort, Duck Key, Marathon, Florida October 24-26, 1994 Sponsored by the IEEE Communications Society The Ninth IEEE Workshop on Computer Communications will be held October 24-26, 1994, at Hawk's Cay Resort, Duck Key, Marathon, Florida, located within two hours of Miami and one hour from Key West. The objective of this workshop is to foster the exchange of information among researchers in this fast-moving field. The program includes presentations by distinguished researchers, speaking on recent advances in theory and practice, with ample time for discussions both between presentations and at the end of each session. As it is now traditional in our workshop, all attendees are encouraged to participate actively in the discussions, comment on presentations, challenge the speakers, and present different viewpoints. Topics to be covered in the technical sessions include: o ATM LANs o Optical Networks o Video Communication o Mobile Computing o Wireless Networks o Multimedia Networking o Modeling and Analysis of Computer Communications o Traffic Management in ATM Networks Each session will include four 25-minute presentations by invited speakers (or the interested parties can contact the session chairs for a possible time slot for a presentation). Attendance is limited to 100 people. Important Dates: August 15, 1994: Deadline for receipt of applications for attendance. September 1, 1994: Mailing of final program to attendees and receipt of workshop registration fee $90. Please direct inquiries to: Ian F. Akyildiz Imrich Chlamtac Workshop Chair Workshop Co-Chair School of ECE Department of ECE Georgia Tech UMASS Atlanta, GA 30332 Amherst, MA 01003 Tel.: 404-894-5141 Tel.: 413-545-0712 Fax.: 404-853-9410 Fax.: 413-545-4611 E_Mail: ian@armani.gatech.edu E_Mail: chlamtac@ecs.umass.edu -------------------------------------------------------------------------- PRELIMINARY PROGRAM Ninth Annual Workshop on COMPUTER COMMUNICATIONS Hawk's Cay Resort, Duck Key, Marathon, Florida October 24-26, 1994 Sunday, October 23, 1994 ------------------------ 6-9pm Registration; Wine and Cheese Party Monday, October 24, 1994 ------------------------ 8-10am Session 1: ATM LANs Izhak Rubin and Yoram Ofek rubin@ee.ucla.edu ofek@watson.ibm.com 10-10:30am Break 10:30am-12:30pm Session 2: Video Services and Networking Support Simon S. Lam lam@cs.utexas.edu 12:30-3pm Lunch 3-6pm Session 3: Traffic Management in ATM Networks John Daigle and Brad Makrucki daigle@gateway.mitre.org brad@bss.com 4:30-5pm Break 7pm. Buffet Dinner Tuesday, October 25, 1994 ------------------------- 8-10am Session 4: Optical Networks Hisashi Kobayashi hisashi@princeton.edu 10-10:30am Break 10:30am-12:30pm Session 5: Network Performance Khosrow Sohraby and Kazem Sohraby sohraby@cstp.umkc.edu kas1@hoserve.ho.att.com 12:30-3pm Lunch 3-6pm Session 6: Multimedia Networking Domenico Ferrari and Hui Zhang ferrari@tenet.berkeley.edu hzhang@george.lbl.gov 4:30-5pm Break 7pm. Buffet Dinner Wednesday, October 26, 1994 --------------------------- 8-10am Session 7: Wireless Networks Gordon Stuber stuber@eecom.gatech.edu 10-10:30am Break 10:30am-12:30pm Session 8: Mobile Computing Nachum Shacham shacham@sri.com ------------------------------------------------------------------------- 1994 IEEE COMPUTER COMMUNICATIONS WORKSHOP PRE-REGISTRATION FORM Name: _______________________________ Company/Affiliation: _________________________________ Address: ____________________________________ ____________________________________ Tel.: ____________________ Fax.: ___________________ E_Mail: _________________ ___ $90 enclosed (Make check payable to "WORKSHOP'94") Mail to: Prof. Ian F. Akyildiz School of ECE Georgia Tech Atlanta, GA 30332 Tel.: (404)-894-5141 Fax.: (404)-853-9410 E_Mail.: ian@armani.gatech.edu From rem-conf-request@es.net Mon Jun 06 16:56:48 1994 Received: from violin.dcs.uky.edu by osi-west.es.net via ESnet SMTP service id <24412-0@osi-west.es.net>; Mon, 6 Jun 1994 13:56:11 +0000 Received: from localhost.uky.edu by violin.dcs.uky.edu (4.1/UKY_DCS_RAJ-1.2) id ; Mon, 6 Jun 94 16:53:26 EDT Message-Id: <9406062053.AA06605@violin.dcs.uky.edu> To: rem-conf@es.net Cc: lakshman@dcs.uky.edu Subject: CALL FOR PAPERS Date: Mon, 06 Jun 94 16:53:24 -0400 From: Lakshman K =========================================================================== CALL FOR PAPERS COMPUTER COMMUNICATIONS: SPECIAL ISSUE ON SYSTEM SUPPORT FOR MULTIMEDIA COMPUTING =========================================================================== The international data communications research journal "Computer Communications" announces a special issue on System Support for Multimedia Computing Guest Editor: Professor Kevin Jeffay Department of Computer Science, University of North Carolina at Chapel Hill Inexpensive hardware for processing digitized audio and video data is rapidly becoming available for desktop PCs. At the same time, high network bandwidth at relatively low price is now widely available at the desktop. This has led to the development of applications and technologies for computer-based conferencing. This special issue of "Computer Communications" aims to present and document current research in operating and network support for multimedia conferencing. The focus will be on transport protocols and allied issues. Relevant topics include: - media synchronization schemes - admission control - conference control - jitter control schemes - congestion/flow management schemes - application-level protocols - real-time resource allocation algorithms - practice and experience - performance models and studies. IMPORTANT DATES: Submissions due: August 15, 1994 Author notification: Nov. 15, 1994 Publishing date: July 1995 AUTHOR INFORMATION: Submissions made to the special issue should not have appeared in, or been submitted to other archival publications. All papers will be subjected to the journal's usual refereeing process. Papers developed from earlier conference and workshop presentations are welcome. Prospective authors should send six copies of their manuscript (in English) to the guest editor: Professor K Jeffay, Department of Computer Science, University of North Carolina at Chapel Hill, Chapel Hill,, NC 27599-3175, USA. Tel: +1 919 962 1938; Fax: +1 919 962 1799; Email: jeffay@cs.unc.edu Authors are advised to consult the journal's 'Notes for Authors' and 'Notes for Authors Submitting on Disk', published in the journal or available from the General Editor (PO Box 31, Market Harborough, Leics LE16 9RQ, UK) or from the US Editor (Raj Yavatkar, Department of Computer Science, University of Kentucky, 40506-0027, USA, raj@dcs.uky.edu) before submitting their papers. From rem-conf-request@es.net Tue Jun 07 02:53:09 1994 Received: from sangam.ncst.ernet.in by osi-west.es.net via ESnet SMTP service id <25509-0@osi-west.es.net>; Mon, 6 Jun 1994 23:52:47 +0000 Received: (from uucp@localhost) by sangam.ncst.ernet.in (8.6.8.1/8.6.6) with UUCP id MAA02013; Tue, 7 Jun 1994 12:22:15 +0530 Received: by henna.iitd.ernet.in (4.1/SMI-4.1-MHS-7.0 ) id AA04929; Tue, 7 Jun 94 11:54:55 IST X-Organisation: Indian Institute of Technology, New Delhi. Date: Tue, 7 Jun 1994 11:50:21 +0530 (IST) From: Palepu Srinivas Sender: Palepu Srinivas Reply-To: Palepu Srinivas Subject: Multicast Addressing To: rem-conf@es.net, mbone@isi.edu Cc: palepu@henna.iitd.ernet.in Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII The issue of multicast address management was dealt with in RFC 1458 entitled "Requirements for Multicast Protocols" dated May 1993. In that RFC, a hierarchical Multicast Group Authority (MGA) was proposed. Furthermore, these addresses are supposed to be dynamically allotted and de-allotted. I am interested in knowing : 1. if there is one internet-wide unique root of MGA, and if yes, as to where is it located and how one gets an address allocated and de-allocated. 2. if this job is totally decentralized (several roots), which can lead to some chaos or inefficient use of address-space. I shall appreciate any information, whatsoever, on this subject. With so many conferences, etc being multicasted these days, I am sure that the solution must be widely known already. I seem to have missed the literature, information,... in this area, and am requesting for the same, now. Thanks in advance. Srinivas Palepu ============================================================================= Srinivas Palepu palepu@henna.iitd.ernet.in Ph: (W) +91-11-686 7431 Deptt of Comp.Sc & Engg Voice Mail +91-11-376 0520 IIT Hauz Khas, N.Delhi-16 Fax +91-11-686 8765 ----------------------------------------------------------------------------- From rem-conf-request@es.net Tue Jun 07 13:28:10 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <28614-0@osi-west.es.net>; Tue, 7 Jun 1994 10:27:30 +0000 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14959(3)>; Tue, 7 Jun 1994 10:22:49 PDT Received: by redwing.parc.xerox.com id <57153>; Tue, 7 Jun 1994 10:22:40 -0700 Date: Tue, 7 Jun 1994 10:22:31 PDT Sender: Lixia Zhang From: Lixia Zhang To: rem-conf-request@es.net Cc: rem-conf@es.net Subject: Re: Reliable transport for multicasting In-Reply-To: Your message of Tue, 7 Jun 1994 07:03:24 -0700 Message-ID: > I am interested in the topic of "reliable transport for multicasting". > Any pointers are welcome. Based on Van's scheme embedded in wb, a few of us at PARC just started working out a reliable transport scheme (in collaboration with Sally Floyd). We expect some preliminary results by end of summer. From rem-conf-request@es.net Tue Jun 07 13:39:28 1994 Received: from uswat.advtech.uswest.com by osi-west.es.net via ESnet SMTP service id <28663-0@osi-west.es.net>; Tue, 7 Jun 1994 10:38:51 +0000 Received: from moly.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA17099 (5.67b/IDA-1.5 for ); Tue, 7 Jun 1994 11:38:42 -0600 Received: by moly.advtech.uswest.com (advtech.uswest.com) id AA00384 (5.0/at-generic.8Nov93); Tue, 7 Jun 1994 11:32:16 +0700 Date: Tue, 7 Jun 1994 11:32:16 +0700 From: Michael Cain Message-Id: <9406071732.AA00384@moly.advtech.uswest.com> To: rem-conf@es.net Subject: Re: Mbone tools for PCs running Solaris? Content-Length: 2470 > >> Have any of the mbone tools (vat, wb, nv, etc.) have been > >> ported to PCs running Solaris? > > > > If not, I am interested/willing/able to do the port.... > > > I would expect nv to "just work", to at least the same extent that it works on > Solaris 2.x for SPARCs. I don't know what video hardware you'd use, though. You > may only be able to run it receive-only (or transmitting X11 screen shots) > right now. Some information (I'd hesitate to call them insights) based on our experience with using PCs running linux as sources and sinks for compressed video over our data network: 1) Local bus display boards (VESA or PCI) provide a lot of benefit for received video. The ISA bus in the PC is a horrible bottle- neck, and can put you in the unpleasant situation of using up most of a fast processor just trying to put the image sequence up on the screen. 2) I'm using a monochrome frame grabber from Control Vision (1-800- 292-1160). My capture-and-compression software runs as root but is not a device driver in the true sense of that term. 240x180 pixel images at 10-15 frames/sec take up most of a 66~Mhz '486. Profiling my code breaks things down to roughly 40% of the time spent copying images out of the frame grabber (there's that ISA bus again), 40% of the time doing compression and 20% of the time in a polling loop waiting for a frame grab to end. The 20% could be recovered if I wrote a real device driver since the board can generate an interrupt at the beginning of each vertical refresh. However, I'm reluctant to have a device driver that uses 40% of the CPU cycles. Much of the 40% spent copying could be eliminated if (a) the grabber sat on the local bus or (b) the grabber supported DMA. Control Vision says they have a local bus grabber in design. 3) I'm looking at grabbers with an onboard processor (typically a DSP of some flavor) that could do all of the compression job, but they're a lot more expensive. 4) Ron has done a nice job of isolating the video hardware dependencies in nv, so it's probably not a real big job to hack in the code to run a grabber like Control Vision's. I'd probably spawn a seperate processor to handle the hardware and communicate by shared memory. If linux supported multicast, I'd probably have already done it. Michael Cain U S WEST Advanced Technologies Boulder, CO mcain@advtech.uswest.com From rem-conf-request@es.net Tue Jun 07 15:32:36 1994 Received: from sirius.ctr.columbia.edu by osi-west.es.net via ESnet SMTP service id <29340-0@osi-west.es.net>; Tue, 7 Jun 1994 12:32:00 +0000 Received: from pawnee.ctr.columbia.edu (sassan@pawnee.ctr.columbia.edu [128.59.66.24]) by sirius.ctr.columbia.edu (8.6.7/8.6.4.287) with ESMTP id PAA27490; Tue, 7 Jun 1994 15:31:56 -0400 From: sassan@ctr.columbia.edu (Sassan Pejhan) Received: (sassan@localhost) by pawnee.ctr.columbia.edu (8.6.7/8.6.4.788743) id PAA12670; Tue, 7 Jun 1994 15:31:54 -0400 Date: Tue, 7 Jun 1994 15:31:54 -0400 Message-Id: <199406071931.PAA12670@pawnee.ctr.columbia.edu> To: sree@iti.gov.sg Subject: Re: Multicast Addressing Cc: rem-conf@es.net > An interesting paper that discusses the use of Multicast Group Address > Management and Control is described in the following paper : > > Multicast Group Address Management and Connection Control for Multi-party > Applications, Alexandrios Eleftheriadis, Sassan Pejhan and Dimitris > Anastassiou, Center For Telecommunications Research, Columbia University, > April 26, 1993. > > The multicast group address space is algorithmically derived from the IP > network address. Each network thus has a limited number of multicast > addresses and they are managed by a Multicast Address Manager (MAM), one > per network. MAMs are aware of other MAMs and can borrow m/cast addresses > when they run out of addresses. > Actually, we now have an improved version of the solution proposed in that paper which employs a fully distributed scheme (one MAM per host). The improved version is described in a technical report, which may be retrieved via anonymous ftp from ftp.ctr.columbia.edu cd CTR-Research/advent/public/papers/94 get pej94a.ps.Z The distributed scheme has a number of advantages over the older, semi-distributed scheme, which are discussed in the technical report. We also compare the two schemes with two other proposed solutions: that of RFC 1458 (MGA hierarchy) and a scheme proposed by IBM-Heidelberg, albeit in the context of LANs only. > We intend to use the proposed scheme in our Conference Management Servers > which will dynamically allocate addresses as conferences are convened and > de-allocate them as they are completed. > > regards, > Sree > We'd be happy to receive any feedback on the implementation of the scheme. Again, I would suggest implementing the newer version, which is much more efficient. Sassan Pejhan From rem-conf-request@es.net Tue Jun 07 16:55:47 1994 Received: from adept.PRPA.Philips.COM by osi-west.es.net via ESnet SMTP service id <29692-0@osi-west.es.net>; Tue, 7 Jun 1994 13:55:05 +0000 Received: from jeanet.PRPA.Philips.COM by adept.PRPA.Philips.COM (4.1/SMI-4.1) id AA28799; Tue, 7 Jun 94 13:55:21 PDT Received: by jeanet.PRPA.Philips.COM (4.1/SMI-4.1) id AA17440; Tue, 7 Jun 94 13:55:27 PDT Date: Tue, 7 Jun 94 13:55:27 PDT From: nichols@jeanet.PRPA.Philips.COM (Kathleen Nichols) Message-Id: <9406072055.AA17440@jeanet.PRPA.Philips.COM> To: rem-conf@es.net Subject: Hot Interconnects II HOT INTERCONNECTS II A Symposium on High-Performance Interconnects Sponsored by the Technical Committee on Microprocessors and Microcomputers of the IEEE Computer Society. Stanford University Memorial Audiorium Palo Alto, CA August 11-13, 1994 Attend Hot Interconnects II, a symposium focusing on the architecture and implementation of high performance interconnects of all scales. Hot Interconnects offers a broad technical program emphasizing real solutions. Enjoy the informal format offering interaction with speakers and the chance to share experiences with professionals working on a range of interconnect types. Presentations will include the latest products as well as current research. See what's hot in ATM, PCI, SuperClusters, MPPs, WANs and more! This is an advance program. Sessions may be dropped, added or moved between days. Get the latest information on the conference via xmosaic or ftp on WWW from URL: file:://now.cs.berkeley.edu/pub/html/HotI THURSDAY, AUGUST 11, 1994 8:45-9:00 Welcome and Opening Remarks 9:00-10:00 Keynote Presentation High-Speed Host Interfaces to ATM Networks Dave Sincoskie, Bellcore 10:30-12:00 ATM Cards ATM: Integration with Legacy LANS, Applications & Networks in Use Today George Prodan, FORE Systems, Inc. Reducing the Complexity of ATM Host Interfaces Henry H. Houh and David L. Tennenhouse, MIT Lab for Computer Science A Memory Integrated Network Interface Ron Monnich, Dan Burns, Frank Hady, and Kevin Smith Supercomputing Research Center 1:30-3:00 SuperClusters A Case for NOW (Networks-of-Workstations) David Patterson, U.C. Berkeley HPAM: an Active Message Layer for a Network of HP Workstations Richard Martin, U.C. Berkeley Low Latency Communication Over ATM Networks Using Active Messages Thorsten von Eicken, Cornell University 3:30-5:30 Peripheral Interconnects Gigabit Design Techniques for PCI Rick Coulson, Intel Fiber Channel: Oversold? Overhyped? Overdue? Neil Lincoln, Supercomputer Systems Engineering and Services Company A Fibre Channel Protocol Chip Steve Dean, Hewlett-Packard TNet: A Reliable System Area Network for I/O and IPC Robert W. Horst, Tandem Computers Inc. 5:30 Reception and Buffet Dinner 8:00 Panel: Low Latency: Can we get it? Can we live without it? Moderator: Gordon Bell FRIDAY, AUGUST 12, 1994 8:30-9:15 Keynote Presentation Myrinet - A Gb/s Local-Area Network Chuck Seitz, Myricom, Inc. 9:15-10:45 Hot Routing Chips nCUBE3 Interprocessor Communications - Reliable Messaging and Adaptive Routing Robert Duzett, nCUBE SP2 High-Performance Switch Architecture Craig B. Stunkel and Peter H. Hochschild IBM Thomas J. Watson Research Center The Reliable Router: A Reliable and High-Performance Communication Substrate for Parallel Computers William J. Dally, Larry R. Dennison, David Harris, Kinhong Kan and Thucydides Xanthopoulos, MIT Artificial Intelligence Laboratory 11:00-12:30 Alternative Network Interfaces Network Interface Support for Virtual Memory Mapped Communication Kai Li, Princeton University Network Substrate for Parallel Processing on a Workstation Cluster James Ho and Andy Boughton, MIT Laboratory for Computer Science HotPads - Macro-cells for Gigabit I/O Deog-Kyoon Jeong, David D. Lee, Duane Northcutt, Andreas v. Bechtolsheim Seoul University, LSI Logic Corp, and Sun Microsystems 2:00-3:30 Transporting Multimedia The Future Internet Architecture Scott Shenker, Xerox PARC Bay Area Gigabit Testbed Network (BAGNet): A High Speed, Metropolitan Area, ATM Network Bill Johnston, Marjory Johnson, Dan Swinehart, Yuet Lee, and Rick Hronicek, Lawrence Berkeley Lab, RIACS/ NASA Ames Research Center, Xerox PARC, Pacific Bell, CalREN PCI for Multimedia Applications, Dave Carson, Intel 4:00-5:30 Hot Air: Wireless Networks Data Services for CDMA Cellular Systems Gadi Karmi, Qualcomm, Inc. CDPD: A Progress Report Dave Lyon, PCSI, Inc. Measured Performance of an In-Building Cellular Radio Network Alan J. Demers and Christopher A. Kantarjiev, Xerox PARC SATURDAY, AUGUST 13, 1994 8:30-12:00 MORNING TUTORIALS 1) ATM Networking by James D. McCabe This tutorial will describe the reasons for developing ATM, potential applications for ATM based supercomputer networks, and the evolution towards services-based networking. 2) Introduction to PCI Design by Tim Mostad This tutorial will give an overview of the Peripheral Component Interconnect, PCI, which is highly likely to become the choice for the new generations of powerful microprocessor based systems. 3) Digital Audio and Video by Lawrence A. Rowe This tutorial will describe the human audio and visual systems, the major compression standards, and their interactions. This knowledge is needed for the first part of the afternoon tutorial. 1:30-5:00 AFTERNOON TUTORIALS 4) FibreChannel by the FibreChannel Association This tutorial will present the advantages, the overview, the status, and future directions of Fibre Channel. 5) Multimedia Infrastructure and Surfing the Internet by Lawrence A. Rowe This tutorial will cover multimedia infrastructure including hardware platforms, network technology, storage systems, and software, and will survey possible future directions and standards. The latter part is a beginners' guide to using mosaic to cruise the internet. Luncheon is included in the $100 fee per tutorial. ORGANIZING COMMITTEE General Chair: Paul Borrill, Sun Microsystems Program Co-Chairs: David E. Culler, UC Berkeley Kathleen Nichols, Philips Research Palo Alto Local Arrangements: Dusan Jevtic, Santa Clara University Registration: Qiang Li, Santa Clara University Treasurer: Dima Khoury, TTC of Silicon Valley Publicity: S. Diane Smith, Consultant Tutorials: Doreen Cheng NASA Ames PROGRAM COMMITTEE MEMBERS Hasan AlKhatib, Santa Clara University Dal Allan, ENDL Gordon Bell, Consultant Paul Borrill, Sun Microsystems Computer Corp. Andrew Chien, University of Illinois Bob Felderman, Myricom, Inc. Mike Gougen, Synoptics, ATM Forum Anoop Gupta, Stanford University Marjory Johnson, RIACS/NASA Ames Larry Peterson, University of Arizona Jim Schuessler, National Semiconductor Corp. Doug Terry, Xerox PARC Audrey Viterbi, Qualcomm, Inc. FEES for the TECHNICAL PROGRAM (Thursday and Friday): Early registration is before July 11, 1994. Fees for registration after July 11 are in parentheses. IEEE/CS or ACM Member: $210 ($265) Non-Member: $265 ($330) Unemployed: $180 ($235) Student Member: $55 ($125) Registration for the Technical Program includes: attendance; one copy of the notes; parking; Thursday evening dinner and reception; two lunches; coffee breaks. A Stanford map, parking permit, the location of parking, and a receipt will be mailed to early registrants. FEES for the TUTORIAL PROGRAM (Saturday): Early registration is before July 11, 1994. Fees for registration after July 11 are in parentheses. The following fees apply to each individual tutorial. Luncheon is included. IEEE/CS or ACM Member: $100 ($120) Non-Member: $125 ($145) Unemployed: $70 ($85) Student Member: $25 ($35) Cancellation of Registration: Must be made in writing prior to Friday, July 30, 1994. A $40 fee will be charged for cancellation. On-Site Registration will start at 7:30 am, Thursday, August 11, 1994. Registration may be faxed or e-mailed if paid by credit card. To register, contact: Dr. Qiang Li Dept. of Computer Engineering Santa Clara University Santa Clara, CA 95053 Voice: (408)554-2730 Fax: (408)554-5474 Internet: hot-i@sunrise.scu.edu REGISTRATION INFORMATION REQUESTED: Name ______________________________ Affiliation ___________________________ Mailing Address_________________________ ______________________________________ Telephone ______________________________ Fax ___________________________________ Check all that apply: ____ Please don't include my name in any mailing list ____ IEEE Member, membership number ___________________ ____ ACM Member, membership number ___________________ ____ Full-time student ____ Unemployed ____ Please send me housing information Payment Method: _____ Check _____ VISA _____ Mastercard If paying by credit card: Exact cardholder name: ____________________________ Credit Card number: __________________________ Expiration date: _____________________________ SELECTIONS AND FEES: Technical Program: _______ Tutorials: _______ ______ 8:30-12:00 Tutorial: ATM Networking ______ 8:30-12:00 Tutorial: Introduction to PCI Design ______ 8:30-12:00 Tutorial: Digital Audio/Video ______ 1:30-5:00 Tutorial: FibreChannel ______ 1:30-5:00 Tutorial: Multimedia Infrastructure/Internet TOTAL AMOUNT for Technical Program/Tutorials _______ From rem-conf-request@es.net Tue Jun 07 17:23:20 1994 Received: from viipuri.nersc.gov by osi-east.es.net via ESnet SMTP service id <03420-0@osi-east.es.net>; Tue, 7 Jun 1994 14:22:51 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA08048; Tue, 7 Jun 94 14:22:33 PDT Date: Tue, 7 Jun 94 14:22:33 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9406072122.AA08048@viipuri.nersc.gov> To: rem-conf@es.net Subject: Re: Mbone tools for PCs running Solaris? ----- Begin Included Message ----- >From mcain@advtech.uswest.com Tue Jun 7 09:24:27 1994 Date: Tue, 7 Jun 1994 10:17:58 +0700 From: Michael Cain To: rem-conf-request@es.net Subject: Re: Mbone tools for PCs running Solaris? Content-Length: 2470 > >> Have any of the mbone tools (vat, wb, nv, etc.) have been > >> ported to PCs running Solaris? > > > > If not, I am interested/willing/able to do the port.... > > > I would expect nv to "just work", to at least the same extent that it works on > Solaris 2.x for SPARCs. I don't know what video hardware you'd use, though. You > may only be able to run it receive-only (or transmitting X11 screen shots) > right now. Some information (I'd hesitate to call them insights) based on our experience with using PCs running linux as sources and sinks for compressed video over our data network: 1) Local bus display boards (VESA or PCI) provide a lot of benefit for received video. The ISA bus in the PC is a horrible bottle- neck, and can put you in the unpleasant situation of using up most of a fast processor just trying to put the image sequence up on the screen. 2) I'm using a monochrome frame grabber from Control Vision (1-800- 292-1160). My capture-and-compression software runs as root but is not a device driver in the true sense of that term. 240x180 pixel images at 10-15 frames/sec take up most of a 66~Mhz '486. Profiling my code breaks things down to roughly 40% of the time spent copying images out of the frame grabber (there's that ISA bus again), 40% of the time doing compression and 20% of the time in a polling loop waiting for a frame grab to end. The 20% could be recovered if I wrote a real device driver since the board can generate an interrupt at the beginning of each vertical refresh. However, I'm reluctant to have a device driver that uses 40% of the CPU cycles. Much of the 40% spent copying could be eliminated if (a) the grabber sat on the local bus or (b) the grabber supported DMA. Control Vision says they have a local bus grabber in design. 3) I'm looking at grabbers with an onboard processor (typically a DSP of some flavor) that could do all of the compression job, but they're a lot more expensive. 4) Ron has done a nice job of isolating the video hardware dependencies in nv, so it's probably not a real big job to hack in the code to run a grabber like Control Vision's. I'd probably spawn a seperate processor to handle the hardware and communicate by shared memory. If linux supported multicast, I'd probably have already done it. Michael Cain U S WEST Advanced Technologies Boulder, CO mcain@advtech.uswest.com ----- End Included Message ----- From rem-conf-request@es.net Tue Jun 07 17:25:11 1994 Received: from md.interlink.com by osi-west.es.net via ESnet SMTP service id <29874-0@osi-west.es.net>; Tue, 7 Jun 1994 14:24:30 +0000 Received: by md.interlink.com (5.0/SMI-SVR4) id AA01844; Tue, 7 Jun 1994 17:00:48 +0500 Date: Tue, 7 Jun 1994 17:00:48 +0500 To: cam@axle.md.interlink.com, cost237-transport@comp.lancs.ac.uk, end2end-interest@ISI.EDU, f-troup@aurora.cis.upenn.edu, hipparch@sophia.inria.fr, rem-conf-request@es.net, rem-conf@es.net, reres@laas.fr, sigmedia@bellcore.com, sound@acm.org, xtp-relay@cs.concordia.ca Subject: Message intended for you WORKSHOP_ANNOUNCEMENT From: ian@armani.gatech.edu (Ian F. Akyildiz) Message-Id: <9406061919.AA27049@armani.gatech.edu> Content-Type: text Content-Length: 4649 Content-Length: 4635 CALL FOR PARTICIPANTS AND ANNOUNCEMENT Ninth Annual Workshop on COMPUTER COMMUNICATIONS Hawk's Cay Resort, Duck Key, Marathon, Florida October 24-26, 1994 Sponsored by the IEEE Communications Society The Ninth IEEE Workshop on Computer Communications will be held October 24-26, 1994, at Hawk's Cay Resort, Duck Key, Marathon, Florida, located within two hours of Miami and one hour from Key West. The objective of this workshop is to foster the exchange of information among researchers in this fast-moving field. The program includes presentations by distinguished researchers, speaking on recent advances in theory and practice, with ample time for discussions both between presentations and at the end of each session. As it is now traditional in our workshop, all attendees are encouraged to participate actively in the discussions, comment on presentations, challenge the speakers, and present different viewpoints. Topics to be covered in the technical sessions include: o ATM LANs o Optical Networks o Video Communication o Mobile Computing o Wireless Networks o Multimedia Networking o Modeling and Analysis of Computer Communications o Traffic Management in ATM Networks Each session will include four 25-minute presentations by invited speakers (or the interested parties can contact the session chairs for a possible time slot for a presentation). Attendance is limited to 100 people. Important Dates: August 15, 1994: Deadline for receipt of applications for attendance. September 1, 1994: Mailing of final program to attendees and receipt of workshop registration fee $90. Please direct inquiries to: Ian F. Akyildiz Imrich Chlamtac Workshop Chair Workshop Co-Chair School of ECE Department of ECE Georgia Tech UMASS Atlanta, GA 30332 Amherst, MA 01003 Tel.: 404-894-5141 Tel.: 413-545-0712 Fax.: 404-853-9410 Fax.: 413-545-4611 E_Mail: ian@armani.gatech.edu E_Mail: chlamtac@ecs.umass.edu -------------------------------------------------------------------------- PRELIMINARY PROGRAM Ninth Annual Workshop on COMPUTER COMMUNICATIONS Hawk's Cay Resort, Duck Key, Marathon, Florida October 24-26, 1994 Sunday, October 23, 1994 ------------------------ 6-9pm Registration; Wine and Cheese Party Monday, October 24, 1994 ------------------------ 8-10am Session 1: ATM LANs Izhak Rubin and Yoram Ofek rubin@ee.ucla.edu ofek@watson.ibm.com 10-10:30am Break 10:30am-12:30pm Session 2: Video Services and Networking Support Simon S. Lam lam@cs.utexas.edu 12:30-3pm Lunch 3-6pm Session 3: Traffic Management in ATM Networks John Daigle and Brad Makrucki daigle@gateway.mitre.org brad@bss.com 4:30-5pm Break 7pm. Buffet Dinner Tuesday, October 25, 1994 ------------------------- 8-10am Session 4: Optical Networks Hisashi Kobayashi hisashi@princeton.edu 10-10:30am Break 10:30am-12:30pm Session 5: Network Performance Khosrow Sohraby and Kazem Sohraby sohraby@cstp.umkc.edu kas1@hoserve.ho.att.com 12:30-3pm Lunch 3-6pm Session 6: Multimedia Networking Domenico Ferrari and Hui Zhang ferrari@tenet.berkeley.edu hzhang@george.lbl.gov 4:30-5pm Break 7pm. Buffet Dinner Wednesday, October 26, 1994 --------------------------- 8-10am Session 7: Wireless Networks Gordon Stuber stuber@eecom.gatech.edu 10-10:30am Break 10:30am-12:30pm Session 8: Mobile Computing Nachum Shacham shacham@sri.com ------------------------------------------------------------------------- 1994 IEEE COMPUTER COMMUNICATIONS WORKSHOP PRE-REGISTRATION FORM Name: _______________________________ Company/Affiliation: _________________________________ Address: ____________________________________ ____________________________________ Tel.: ____________________ Fax.: ___________________ E_Mail: _________________ ___ $90 enclosed (Make check payable to "WORKSHOP'94") Mail to: Prof. Ian F. Akyildiz School of ECE Georgia Tech Atlanta, GA 30332 Tel.: (404)-894-5141 Fax.: (404)-853-9410 E_Mail.: ian@armani.gatech.edu From rem-conf-request@es.net Tue Jun 07 23:54:14 1994 Received: from eclipse.cs.colorado.edu by osi-west.es.net via ESnet SMTP service id <01405-0@osi-west.es.net>; Tue, 7 Jun 1994 20:53:40 +0000 Received: (from evi@localhost) by eclipse.cs.colorado.edu (8.6.9/8.6.9) id VAA04952; Tue, 7 Jun 1994 21:53:33 -0600 Date: Tue, 7 Jun 1994 21:53:33 -0600 From: Evi Nemeth Message-Id: <199406080353.VAA04952@eclipse.cs.colorado.edu> To: rem-conf@es.net Subject: usenix keynote ++ Cc: evi@eclipse.cs.colorado.edu the usenix conference (june 6-10, boston) is honoring the 25th anniversary of unix, 1969-1994. we will broadcast the keynote address, jeopardy game, and arpanet panel: keynote: penn jillette of penn & teller, wednesday, june 8, 9:15-10:30 AM, EDT, mail comments/questions to penn@usenix.org arpanet: thursday, june 9, 5:45-7:00PM, a panel discussion with a theme: 25 years of the ARPANET (broadcast planned, pending hotel wiring). jeopardy: friday, june 10, 4:00-5:00PM, the jeopardy semi-finals (3 games) and finals (1 game) of the Unix historical trivia jeopardy game. real prizes, including a laptop computer. the session is advertised on sd as "USENIX Keynote ++". -evi ps: thanks to those alert folks who noticed that my arithmetic on timezones was a bit off as i implied that boston was about where pakistan sits on the map and that my announcement that suggested EDT was GMT+5 really meant GMT-4. From rem-conf-request@es.net Wed Jun 08 02:58:26 1994 Received: from taurus.cs.nps.navy.mil by osi-west.es.net via ESnet SMTP service id <01657-0@osi-west.es.net>; Tue, 7 Jun 1994 23:57:59 +0000 Received: by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA18131; Tue, 7 Jun 94 23:59:45 PDT Date: Tue, 7 Jun 94 23:59:45 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9406080659.AA18131@taurus.cs.nps.navy.mil> To: rem-conf@es.net Subject: SIGGRAPH 94 MBone preliminary announcement Cc: siggraph94-mbone@ftlsig.metrolink.com SIGGRAPH 94 plans to broadcast on MBone Sunday July 24 through Friday July 29 from Orlando Florida. We hope to send out 2 channels (at default video bandwidth of 128 Kbps) with worldwide scope. Please comment if there are any other MBone events planned for this period. A preliminary home page describing mail list subscriptions to the SIGGRAPH MBone discussion group is at ftp://taurus.cs.nps.navy.mil/pub/auv/SIGGRAPH94/SIGGRAPH94-mbone.html Please subscribe if you will be exhibiting at SIGGRAPH and want to get involved. SIGGRAPH is the premier computer graphics conference. Last year's conference in Anaheim had an attendance of over 35,000. Thanks for checking your calendar! regards, Don Don Brutzman work (408) 656-2149 Code OR/Br Naval Postgraduate School [Glasgow 204] fax (408) 656-2595 Monterey California 93943-5000 USA home (408) 372-0190 From rem-conf-request@es.net Wed Jun 08 03:05:13 1994 Received: from taurus.cs.nps.navy.mil by osi-west.es.net via ESnet SMTP service id <01884-0@osi-west.es.net>; Wed, 8 Jun 1994 00:04:41 +0000 Received: by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA18267; Wed, 8 Jun 94 00:06:13 PDT Date: Wed, 8 Jun 94 00:06:13 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9406080706.AA18267@taurus.cs.nps.navy.mil> To: rem-conf@es.net Subject: IEEE AUV 94 MBone preliminary announcement Cc: abennett@mit.edu, auv94@ieee.org Autonomous Underwater Vehicles 94 plans to broadcast on MBone Tuesday July 19 and Wednesday July 20. We hope to send out a single channel (at default video bandwidth of 128 Kbps) with worldwide scope. Please comment if there are any other MBone events planned for this period. An excerpt from the advance program follows. It is available at ftp://taurus.cs.nps.navy.mil/pub/auv/auv94.program (text) and ftp://taurus.cs.nps.navy.mil/pub/auv/auv94.ps (postscript). Thanks for checking your calendar! regards, Don Don Brutzman work (408) 656-2149 Code OR/Br Naval Postgraduate School [Glasgow 204] fax (408) 656-2595 Monterey California 93943-5000 USA home (408) 372-0190 =============== IEEE Oceanic Engineering Society Symposium on Autonomous Underwater Vehicle Technology AUV 94 July 19-20, 1994 Charles Stark Draper Laboratories Cambridge, Massachusetts USA The IEEE Oceanic Engineering Society is sponsoring the next Symposium on Autonomous Underwater Vehicle Technology (AUV 94) on July 19-20, 1994. The Symposium will be held at the Charles Stark Draper Laboratories in Cambridge, Massachusetts USA. The focus of the Symposium is AUTONOMOUS OPERATION OF UNDERWATER VEHICLES. Topics include but are not limited to: Sensors and Multi-Sensor Fusion Communications and Telemetry Navigation Imaging Techniques and Systems Modeling and Simulation Methods Mission Control and Software Architectures Energy Systems Autonomous Manipulation Vehicle Design and Control Launch and Recovery Techniques and Issues Multiple Cooperating Vehicles Scientific and Environmental Applications From rem-conf-request@es.net Wed Jun 08 03:32:59 1994 Received: from taurus.cs.nps.navy.mil by osi-west.es.net via ESnet SMTP service id <01994-0@osi-west.es.net>; Wed, 8 Jun 1994 00:32:22 +0000 Received: by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA18763; Wed, 8 Jun 94 00:34:05 PDT Date: Wed, 8 Jun 94 00:34:05 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9406080734.AA18763@taurus.cs.nps.navy.mil> To: rem-conf@es.net Subject: SIGGRAPH 94 MBone preliminary announcement [Apologies if this is a repeat. The first copy did not return to me.] SIGGRAPH 94 plans to broadcast on MBone Sunday July 24 through Friday July 29 from Orlando Florida. We hope to send out 2 channels (at default video bandwidth of 128 Kbps) with worldwide scope. Please comment if there are any other MBone events planned for this period. A preliminary home page describing mail list subscriptions to the SIGGRAPH MBone discussion group is at ftp://taurus.cs.nps.navy.mil/pub/auv/SIGGRAPH94/SIGGRAPH94-mbone.html Please subscribe if you will be exhibiting at SIGGRAPH and want to get involved. SIGGRAPH is the premier computer graphics conference. Last year's conference in Anaheim had an attendance of over 35,000. Thanks for checking your calendar! regards, Don Don Brutzman work (408) 656-2149 Code OR/Br Naval Postgraduate School [Glasgow 204] fax (408) 656-2595 Monterey California 93943-5000 USA home (408) 372-0190 From rem-conf-request@es.net Wed Jun 08 05:01:27 1994 Received: from sicmail.epfl.ch by osi-west.es.net via ESnet SMTP service id <02467-0@osi-west.es.net>; Wed, 8 Jun 1994 02:00:54 +0000 Received: from tcomhp24.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <09649-0@sicmail.epfl.ch>; Wed, 8 Jun 1994 11:00:45 +0200 Received: by tcomhp20.epfl.ch (1.37.109.4/Epfl-3.1/MX) id AA20836; Wed, 8 Jun 94 11:04:07 +0200 From: pusztas@tcomhp20.epfl.ch (Yu-Hong Pusztaszeri) Message-Id: <9406080904.AA20836@tcomhp20.epfl.ch> Subject: Please add me in the mailing list! To: rem-conf@es.net Date: Wed, 8 Jun 94 11:04:06 METDST Cc: yhp@tcom.epfl.ch X-Hpvue$Revision: 1.8 $ Mime-Version: 1.0 Content-Type: Message/rfc822 X-Vue-Mime-Level: 4 Mailer: Elm [revision: 70.85] Hi! I would like to be in your mailing list. My E-mail address is yhp@tcom.epfl.ch. Thanks. Greetings Yu-Hong From rem-conf-request@es.net Wed Jun 08 17:44:31 1994 Received: from fenris.dhhalden.no by osi-west.es.net via ESnet SMTP service id <05007-0@osi-west.es.net>; Wed, 8 Jun 1994 14:44:04 +0000 Received: from sofus.dhhalden.no by fenris.dhhalden.no with SMTP (PP) id <23363-0@fenris.dhhalden.no>; Wed, 8 Jun 1994 18:37:27 +0200 Received: from SOFUS/MERCURY by sofus.dhhalden.no (Mercury 1.11); Wed, 8 Jun 94 18:37:19 GMT+1 Received: from MERCURY by SOFUS (Mercury 1.11); Wed, 8 Jun 94 18:37:03 GMT+1 From: Bard Arve Evjen Organization: Ostfold College To: rem-conf@es.net Date: Wed, 8 Jun 1994 18:36:56 +0100 Subject: Unsub Priority: normal X-mailer: Pegasus Mail v3.1 (R1) Message-ID: Sorry about posting to the whole list, but I just can't get off this list. Please unsubsribe me! Thanks! Bard Arve =-=-=-=-----=-=-=-=-----=-=-=-=-----=-=-=-=-----=-=-=-=-----=-=-=-= Bard Arve Evjen MultiMedia-student baarde@dhhalden.no (pc60) Servers: Fenris/Sofus/Gyda/Darkwing O/ o~ o_O/ Ostfold Regional College, Norway o/| _______|_______ \ Department of Computer Science / \ | | |\ Freelance jounalist in Lyd & Bilde (lydbilde@telepost.no) URL: http://student.dhhalden.no/prosjekt/IPM/Default.html =-=-=-=-----=-=-=-=-----=-=-=-=-----=-=-=-=-----=-=-=-=-----=-=-=-= From rem-conf-request@es.net Wed Jun 08 18:18:10 1994 Received: from Sun.COM by osi-west.es.net via ESnet SMTP service id <05157-0@osi-west.es.net>; Wed, 8 Jun 1994 15:17:44 +0000 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA15514; Wed, 8 Jun 94 15:17:41 PDT Received: from auckland.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA02765; Wed, 8 Jun 94 11:59:17 PDT Received: by auckland.Eng.Sun.COM (5.0/SMI-SVR4) id AA24876; Wed, 8 Jun 1994 11:56:23 +0800 Date: Wed, 8 Jun 1994 11:56:23 +0800 From: Ross.Finlayson@Eng.Sun.COM (Ross Finlayson) Message-Id: <9406081856.AA24876@auckland.Eng.Sun.COM> To: rem-conf@es.net Subject: Re: Message intended for you WORKSHOP_ANNOUNCEMENT Reply-To: finlayson@Eng.Sun.COM X-Sun-Charset: US-ASCII Content-Length: 211 Sigh... I encourage people to boycott any conference, workshop etc. for which they receive >= 4 identical email announcements. Ross. ps. This message deliberately sent to the "rem-conf" mailing list *only*. From rem-conf-request@es.net Wed Jun 08 18:39:03 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <05330-0@osi-west.es.net>; Wed, 8 Jun 1994 15:38:27 +0000 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14542(5)>; Wed, 8 Jun 1994 15:38:08 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 8 Jun 1994 15:38:02 -0700 To: rem-conf@es.net cc: deering@parc.xerox.com Subject: Xerox PARC Forum talk tomorrow - Networking in Europe Date: Wed, 8 Jun 1994 15:37:58 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jun8.153802pdt.12171@skylark.parc.xerox.com> We expect to transmit audio and video of the following talk on the MBone tomorrow (Thursday, June 9) at 4:00 pm PDT (2300 GMT), subject to getting the speaker's permission. It will be advertised in sd under the names "Xerox PARC Forum - Audio" and "Xerox PARC Forum - Video". Steve ------------ PARC Forum Date: Thursday, 9th June 1994 Time: 4:00pm-5:00pm Place: PARC Auditorium, Xerox PARC, 3333, Coyote Hill Road, Palo Alto CA 94304 Speaker: Jack Kessler, consultant on academic libraries, Internet, Minitel _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ NETWORKING IN EUROPE: MARKET(ING) CRITERIA FOR REACHING THE 'GENERAL PUBLIC' IN EUROPE, ASIA & THE U.S. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ by Jack Kessler Consultant, AKCO, Inc., San Francisco Europe has both Internet and Minitel / Videotex information networking now, making it a convenient laboratory in which to examine different approaches to the looming problem of providing access to the nets to the "general public". In France the general public already is online: in Asia and in the US it isn't. Six characteristics of online access by the general public in Europe may provide insight into attempts to provide such general public networking access in Asia and, eventually, in the US itself. ----------------------------------------------------------------------------- This Forum is OPEN to the Public. All are invited to attend. Refreshments will be served on site at 3:45 p.m. The PARC auditorium is located at 3333 Coyote Hill Road in Palo Alto. We are between Page Mill Road (West of Foothill Expressway) and Hillview Avenue, in the Stanford Research Park. From Page Mill Road, turn onto Coyote Hill Road. Drive Up Coyote Hill past the horse pastures; PARC is the only building on the left, just past the crest of the hill. Due to some construction in our main parking lot, please park in the lot across Coyote Hill Road. Cross the street and enter the auditorium at the upper level of the building. The auditorium entrance is located down the stairs and to the left of the main doors from the outside of the building. From rem-conf-request@es.net Wed Jun 08 23:35:46 1994 Received: from shark.mel.dit.CSIRO.AU by osi-west.es.net via ESnet SMTP service id <06306-0@osi-west.es.net>; Wed, 8 Jun 1994 20:35:12 +0000 Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA21934 (5.65c/IDA-1.4.4/DIT-1.3 for rem-conf@es.net); Thu, 9 Jun 1994 13:35:08 +1000 Message-Id: <199406090335.AA21934@shark.mel.dit.csiro.au> To: rem-conf@es.net Subject: Re: Message intended for you WORKSHOP_ANNOUNCEMENT In-Reply-To: Your message of "Wed, 08 Jun 1994 11:56:23 +0800." <9406081856.AA24876@auckland.Eng.Sun.COM> Date: Thu, 09 Jun 1994 13:35:07 +1000 From: Bob Smart > Sigh... > > I encourage people to boycott any conference, workshop etc. for which they > receive >= 4 identical email announcements. Hmmm, well news handles cross-posting nicely. For e-mail I think it is for the recipient's user interface to solve the problem rather than discouraging people from sending mail to appropriate newsgroups. I use the following python program with mh but I'd be happy to find something better. #!/pub/bin/python # # dup-mail.py keeps a dbm database of MD5 checksums of incoming mail # messages. It actually remembers the msgid of files just in case two # files give the same md5 checksum (?!) this is probably a waste of # diskspace. # # This is meant to be used in an mh .maildelivery file with a line # such as # * - | A "/pub/bin/dup-mail.py" # This will appear (to slocal) to successfully deliver the message if # the message is already in the database. # # You can initialize the database with a command such as # # cd ~/Mail # find . -name '[1-9]*' -exec dup-mail.py '{}' \; -print | tee dup-mail.ls # # This also gives a list of files that are duplicates that you might like to # delete. [The behaviour of -exec seems inverted to me.] from rfc822 import Message from sys import stdin, exit, argv from md5 import md5 from posix import environ import dbm if len(argv) == 1: file = stdin elif len(argv) == 2: file = open( argv[1], 'r') else: print 'usage: dup-mail.py [file]'; exit(2) m = Message(file) d = md5() msgid = m.getheader('Message-Id') subj = m.getheader('Subject') if msgid != None: d.update( msgid) else: msgid = '' if subj != None: d.update( subj) l = file.readline() while l != '': d.update(l) l = file.readline() md = d.digest() db = dbm.open( environ['HOME'] + '/Mail/.mail-md5', 'rw', 0600) try: if db[md] == msgid: exit(0) # we've already got it: say 'delivered' except KeyError: pass db[md] = msgid # remember we got this message exit(1) # and exit saying we haven't delivered the message yet From rem-conf-request@es.net Fri Jun 10 04:18:52 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <12196-0@osi-west.es.net>; Fri, 10 Jun 1994 01:18:20 +0000 Received: from zeus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 10 Jun 1994 09:18:06 +0100 To: rem-conf@es.net Subject: MICE International Seminar: June 21, 1994. Date: Fri, 10 Jun 94 09:18:02 +0100 From: Gordon Joly ** Please limit traffic between 12:30 and 14:30 GMT on Tuesday 21 June At 13:00 GMT/UTC, Professor Lawrence A. Rowe (EECS at Berkeley) will speak on "The Berkeley Distributed Video-on-Demand." An announcement will be made in "sd" on the previous day. Abstract. ----------- The design and implementation of the Berkeley Distributed Video-on-Demand system will be described. The system is designed to store thousands of hours of video material that users can play without having to know the details of where it is located or how to play it. A three-level storage architecture is required because this amount of video is much too large to store on magnetic disks (e.g., 0.5 GB/hour). Videos are stored permanently on tertiary storage devices that are managed by archive servers. Video file servers (VFS) manage a cache of video objects on magnetic disks that can be played by applications running on client workstations. Applications issue requests to play a video. The system locates and plays the video if it is on one of the VFS's. Otherwise, a request is entered to load it from the appropriate archive. A metadata database is maintained by each archive server that contains indexes into the videos managed by that archive. This database can be queried by a user who wants to find a particular video (e.g., a course lecture on LR parser table construction). We have built a prototype system that manages over 12 GBytes of data, and we are digitizing and indexing almost two hours of material a week. This talk will present the design and implementation of this system and discuss current research problems on which we are working. ----------- In general, information on the MICE seminars is kept up to date in the WWW at URL http://www.cs.ucl.ac.uk/mice/seminars/ which should also contain abstracts of future talks. Gordon Joly Phone +44 71 380 7934 FAX +44 71 387 1397 Email G.Joly@cs.ucl.ac.uk Comp Sci, University College, London, Gower Street, LONDON WC1E 6BT XXX YYY WWW & http://www.cs.ucl.ac.uk/mice/gjoly.html & WWW YYY XXX From rem-conf-request@es.net Fri Jun 10 07:25:37 1994 Received: from vision.postech.ac.kr by osi-west.es.net via ESnet SMTP service id <13111-0@osi-west.es.net>; Fri, 10 Jun 1994 04:25:06 +0000 Received: from turing.postech.ac.kr ([141.223.124.2]) by vision.postech.ac.kr (4.1/SMI-4.1) id AA24818; Fri, 10 Jun 94 20:12:10 KST Received: from einstein.postech.ac.kr.cc.postech by turing.postech.ac.kr (4.1/SMI-4.1) id AA02157; Fri, 10 Jun 94 20:25:01 GMT Date: Fri, 10 Jun 94 20:25:01 GMT From: sck@turing.postech.ac.kr (SeongCheon Kim) Message-Id: <9406102025.AA02157@turing.postech.ac.kr> To: rem-conf@es.net Subject: Help Help From rem-conf-request@es.net Fri Jun 10 07:57:21 1994 Received: from owl.nstn.ns.ca by osi-west.es.net via ESnet SMTP service id <13249-0@osi-west.es.net>; Fri, 10 Jun 1994 04:56:38 +0000 Received: from Fox.nstn.ns.ca (fox.nstn.ns.ca [137.186.128.12]) by owl.nstn.ns.ca (8.6.8.1/8.6.6) with SMTP id IAA24245 for ; Fri, 10 Jun 1994 08:56:34 -0300 Received: from [137.186.128.119] (halifax-ts2-19.nstn.ns.ca) by Fox.nstn.ns.ca (4.1/SMI-4.1) id AA29781; Fri, 10 Jun 94 08:56:27 ADT Message-Id: <9406101156.AA29781@Fox.nstn.ns.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 10 Jun 1994 08:58:28 -0500 To: rem-conf@es.net From: bmcmulli@fox.nstn.ns.ca (Bill McMullin) unsubscribe end Please unsubscribe me to this conference if the above didn't do it! Thanks in advance. Bill McMullin InterActive Telecom Ph: 902-832-1014 1550 Bedford Hwy. Fx: 902-832-1015 Sun Tower Suite 304 Em: bmcmulli@fox.nstn.ns.ca Bedford, Nova Scotia B4A 1E6 From rem-conf-request@es.net Fri Jun 10 09:35:39 1994 Received: from mailsun.aber.ac.uk by osi-west.es.net via ESnet SMTP service id <13410-0@osi-west.es.net>; Fri, 10 Jun 1994 06:35:09 +0000 Received: from mailhost.aber.ac.uk (actually saturn.dcs.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (PP); Fri, 10 Jun 1994 14:34:02 +0100 To: rem-conf@es.net cc: dap@aber.ac.uk Subject: Recording VAT and NV sessions Date: Fri, 10 Jun 1994 14:33:59 +0100 Message-ID: <21832.771255239@mailhost.aber.ac.uk> From: Dave Price Dear All, I am attempting to record the output of nv and vat using nv_record and vat_record respectively. I am attempting to do this on the same machine that is generating the traffic. In fact what I am trying to do is to play a video (on a video player..) which is feeding into the Sparcs audio port and a SunVideo card. Using vat and nv I can transmit this over the NET and using nv_record I can catch the video into files. However, I can't seem to get vat_record to catch/see the outgoing sound. Any suggestions? Or indeed does anyone have a better way to sample in the Video tape so I can later transmit it using vat_play and nv_play (or av_play). What I just resorted to was using audiotool to catch the audio and then using vat_play_audio to play that while using nv_play to transmit the video. (But this means I can't use av_play). Thanks for any advice that may arrive.... ----------------------------------------------------------------- | 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 Fri Jun 10 12:22:25 1994 Received: from trystero.radio.com by osi-west.es.net via ESnet SMTP service id <13972-0@osi-west.es.net>; Fri, 10 Jun 1994 09:21:51 +0000 Received: (carl@localhost) by trystero.radio.com (8.6.8/940420.05ccg) id MAA18905 for rem-conf@es.net; Fri, 10 Jun 1994 12:23:34 -0400 Date: Fri, 10 Jun 1994 12:23:34 -0400 From: Carl Malamud Message-Id: <199406101623.MAA18905@trystero.radio.com> To: rem-conf@es.net Subject: Cisco Networkers Conference, Preliminary Announcement Org: Internet Multicasting Service The Internet Multicasting Service will be providing video and audio multicasts of selected technical and plenary sessions from the upcoming Cisco Networkers Conference. An actual schedule and an sd announcement will be published the week of the conference. We'll also provide a permanent WWW archive of the technical talks. The conference dates are June 29-July 1. From rem-conf-request@es.net Fri Jun 10 16:57:20 1994 Received: from usc.edu by osi-west.es.net via ESnet SMTP service id <15342-0@osi-west.es.net>; Fri, 10 Jun 1994 13:56:55 +0000 Received: from catarina.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA09524; Fri, 10 Jun 94 13:56:39 PDT Received: from catarina.usc.edu by catarina.usc.edu (4.1/SMI-4.1+ucs-3.6) id AA14287; Fri, 10 Jun 94 13:59:54 PDT Message-Id: <9406102059.AA14287@catarina.usc.edu> From: Kannan Varadhan To: rem-conf@es.net, smart@mel.dit.csiro.au Subject: Lee Breslau: [smart@mel.dit.csiro.au: Re: Message intended for you WORKSHOP_ANNOUN Date: Fri, 10 Jun 1994 13:59:47 -0700 Sender: kannan@catarina.usc.edu Hi Bob, Someone else pointed this out to me. I haven't been following rem-conf for some time now... Since you indicated you are using MH and slocal, you should look at MH 6.8.+ (most definately in 6.8.3) for the MSGID flag in slocal. syntax: slocal [switches] [address info sender] ... options: [ATTVIBUG] [BIND] [BSD42] [BSD43] [DBMPWD] [FOLDPROT='"0700"'] [ISI] [LOCKF] [MHE] [MHRC] [MIME] [MSGID] [MSGPROT='"0600"'] ^^^^^ [NFS] [NTOHLSWAP] [OVERHEAD] [POP] [POP2] [RPATHS] [RPOP] [SENDMTS] [SENDMTS] [SMTP] [SMTP] [SUN4] [SUN40] [TYPESIG=void] [VSPRINTF] [WHATNOW] [ZONEINFO] With this duplicate messages are pruned by message-id fields automatically, even before a pass through your filters. Here's the blurb from the man pages... Duplicate Message Suppression slocal is able to detect and supress duplicate messages. To enable this, create two empty files in your $HOME directory: .maildelivery.pag and .maildelivery.dir. These are ndbm files which are used to store the Message-IDs of incoming messages. Hope this helps, Kannan ------- Forwarded Message Date: Thu, 09 Jun 1994 13:35:07 +1000 From: Bob Smart Hmmm, well news handles cross-posting nicely. For e-mail I think it is for the recipient's user interface to solve the problem rather than discouraging people from sending mail to appropriate newsgroups. I use the following python program with mh but I'd be happy to find something better. ------- End of Forwarded Message From rem-conf-request@es.net Sun Jun 12 07:47:43 1994 Received: from rx7.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <21356-0@osi-west.es.net>; Sun, 12 Jun 1994 04:47:14 +0000 Received: by rx7.ee.lbl.gov for rem-conf@es.net (5.65/1.44r) id AA10778; Sun, 12 Jun 94 04:48:29 -0700 Message-Id: <9406121148.AA10778@rx7.ee.lbl.gov> To: Dave Price Cc: rem-conf@es.net Subject: Re: Recording VAT and NV sessions In-Reply-To: Your message of Fri, 10 Jun 94 14:33:59 BST. Date: Sun, 12 Jun 94 04:48:28 PDT From: Van Jacobson vat_record doesn't work on the vat sender machine because vat turns off `multicast loopback' & there is no local delivery of packets that it sends. We did this because looping back the packets increases vat's load on the cpu by ~30% and the loopback copies are always simply discarded. (nv_record works because nv sets `multicast loopback' and, in fact, uses the looped back copies to display locally what you're sending.) If you can't run vat_record on a different machine, I think it's possible to make it work using the -m (mixer) flag. If is the conference address, port, id, fmt & ttl then the following essentially simulates loopback by sending a copy of the audio packets to both the conference & port 7777 on the unicast loopback interface: vat_record 127.0.0.1/7777 & vat -m 127.0.0.1/7777 This is a serious kluge but should work (I haven't tested it). Let me know if you try it & have problems. - Van From rem-conf-request@es.net Mon Jun 13 07:23:59 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <26873-0@osi-west.es.net>; Mon, 13 Jun 1994 04:23:31 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Mon, 13 Jun 1994 04:23:27 -0700 Posted-Date: Mon 13 Jun 94 04:22:27 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Mon, 13 Jun 94 04:22:28 PDT Date: Mon 13 Jun 94 04:22:27 PDT From: Stephen Casner Subject: Comments requested: RTP version 2 To: rem-conf@es.net Message-Id: <771506547.0.CASNER@XFR.ISI.EDU> Mail-System-Version: ; Mon, 13 Jun 1994 12:09:21 +0000 Received: by helios.ee.lbl.gov (8.6.8.1/1.43r) id MAA21250; Mon, 13 Jun 1994 12:09:08 -0700 From: floyd@ee.lbl.gov (Sally Floyd) Message-Id: <199406131909.MAA21250@helios.ee.lbl.gov> To: Stephen Casner cc: rem-conf@es.net Subject: Re: Comments requested: RTP version 2 Date: Mon, 13 Jun 94 12:09:06 PDT Steve - One of the open issues in the memo on a "Proposed Revision of RTP" concerns including mechanisms for Ian Wakeman's congestion probe scheme [1]. Is that paper available by anonymous ftp anywhere? - Sally From rem-conf-request@es.net Mon Jun 13 17:38:16 1994 Received: from vse.vse.cz by osi-west.es.net via ESnet SMTP service id <29693-0@osi-west.es.net>; Mon, 13 Jun 1994 12:20:03 +0000 Received: by vse.vse.cz id AA09872 (5.67a8/IDA-1.5 for rem-conf@es.net); Mon, 13 Jun 1994 21:23:35 +0200 Date: Mon, 13 Jun 1994 21:23:35 +0200 From: Milan Sterba Message-Id: <199406131923.AA09872@vse.vse.cz> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: mbone@ISI.EDU Subject: Multicast announcement for INET'94/JENC5 Cc: rem-conf@es.net X-Charset: ASCII X-Char-Esc: 29 Multicast announcement for - INET'94/JENC5 - INET'94, the Annual Conference of the Internet Society held in conjunction with the 5th Joint European Networking Conference (JENC5) Prague, Czech Republic, June 13-17, 1994 Jointly organized by The Internet Society (ISOC) and Reseaux Associes pour la Recherche Europeenne (RARE) -------------- Plenary sessions of the conference as well as the RARE RTC plenary session will be multicasted by nv and vat. All sessions will be announced by sd. The detailed time schedule and program of the multicasting will be the following : June 14th 14:00-18:00 METDST (GMT+0200) How to bring European Research Networking into the year 2000 (RARE Technical Commitee panel session around a new proposed initiative) "To make sure that research networks and associated networks in Europe retain the leading edge, and that we develop, test and implement applications and services that can evolve into the European Information Super Highway, it is essential that ongoing network developments in Europe are coordinated." June 15th 9:00-10:30 METDST (GMT+0200) Opening Session Welcome & Keynote Addresses by: - Mr. George Soros, Founder of the Soros Foundations, New York, USA - Professor Emanuel Ondracek, PhD, Deputy Minister of Education, Czech Republic Chair: Geoff Manning, UK June 15th 14:00-15:30 METDST (GMT+0200) Overview: Technical Programs of the IETF and RARE Introduction by: - Vinton G. Cerf, President of ISOC - Kees Neggers, President of RARE Speakers: Paul Mockapetris, IETF & IESG Chair Erik Huizer, RARE Technical Committee member Chair: Erik Huizer, SURFnet, The Netherlands June 16th 16:00-17:30 METDST (GMT+0200) Panel discussion on 'Industry and the Internet' Chair: Bernhard Plattner, ETH, Switzerland Moderator: Tony Rutkowsky, Internet Society, USA "The interest of the industry in the Internet - both as a resource and as a marketplace - has grown tremendously in the last few years. The panel will explore issues, requirements and future developments as seen from industry leaders" Panelists: Janet M. Perry, ..Manager Higher Education Programs, Novell Vinton G. Cerf, ..Senior Vice President Data Architecture, MCI Paul Scherer, ....Director of Technology Development, 3COM Betsy Huber, .....Manager TCP/IP Technology Marketing Strategy, IBM Tony Peatfield, ..Market Development for Universities and Research (Europe), CISCO Eric Schmidt, ....Chief Technology Officer, SUN Dave Probert, ....European Business Development Manager, June 17th 11:00-12:30 METDST (GMT+0200) Closing Session Farewell & Keynote Addresses Keynote Speakers: - Mr. Thomas Kalil, Director to the National Economic Council, Washington D.C., USA - Mr. Luiz Rodrigues Rossello, Head of Division DG XIII/C on behalf of Mr. Michel Richonnier, Director DG XIII/C, EU Chair: Geoff Manning, UK You are all kindly invited to join us on the mbone. However no audio back channel is foreseen to the auditorium. With best regards Milan Sterba (for local organizers) -- ====================================================================== Prague University of Economics e-mail : Milan.Sterba@vse.cz Computing Center tel : +42 2 24 21 79 00 nam. W. Churchilla 4 home: +42 2 823 78 59 130 67 Praha 3 fax : +42 2 24 22 42 66 Czech republic ======================================================================= From rem-conf-request@es.net Wed Jun 15 02:56:18 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <11890-0@osi-west.es.net>; Tue, 14 Jun 1994 23:55:50 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Tue, 14 Jun 1994 23:55:46 -0700 Posted-Date: Tue 14 Jun 94 23:54:41 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Tue, 14 Jun 94 23:54:43 PDT Date: Tue 14 Jun 94 23:54:41 PDT From: Stephen Casner Subject: Re: Comments requested: RTP version 2 To: mit@cs.tut.fi Cc: rem-conf@es.net Message-Id: <771663281.0.CASNER@XFR.ISI.EDU> In-Reply-To: <199406141403.RAA21870@kaarne.cs.tut.fi> Mail-System-Version: Mikko Tsokkinen wrote: > RTCP FMT packet: The issue of how to use the payload-type field values > is very problematic. Actually the issues related to format fields > should be specified in some sort of session management protocol. The > number of bits reserved for payload type will not be enough for all > different formats, due to very large number of possible combinations > of different encodings eg. bits/sample, sampling rate, television > system etc. I'm in a favour of specifying few defined formats and > leaving several non-assigned numbers that can be dynamically allocated > depending on the application. The predefined formats should be chosen > so that they are the most common formats eg. the ITU-T G-series for > audio and ISO/ITU-T formats for video. The application specific > formats should be binded for that session only using the FMT packets. In the previous specification, with a 6-bit "format" field, we specified that half the space was for predefined formats and half was for dynamically defined formats. The predefined ones included some of the ITU-T G-series for audio, plus the formats we are actively using in vat. Additional formats could either be defined in the higher-level session protocol (e.g., a session directory could give the type code and the corresponding parameters to the application), or via the FMT option/packet. So, I think we are in agreement. The open question is whether the session directory method is sufficient, and therefore the FMT packet should be removed. > Separate data and control: The idea of separate ports for control and > data is good. However the similar problem of allocating of 2 > connections in ST-II is also present in ATM-network. In my opinion > encapsulation of some sort is required in these connection oriented > networks. 16 bit pre-header (=UDP/TCP port number) could be used to > transport the data to different ports in the receiver. 16 bits won't work well because of alignment. The previous spec defined a framing encapsulation that could be included by profile to allow packets from multiple streams to be packaged in one lower-layer packet, where the "Channel ID" provided the multiplexing. That encapsulation was simply a 32-bit length, even though 16 bits of length is enough. Since the "Channel ID" has been removed, we could modify the encapsulation to take care of both functions together: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | port | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Here this port number would not strictly be a UDP/TCP port number, but would serve a similar multiplexing function. Control and data could be indicated by separate port numbers, as they would be with UDP. A key concern to consider: We want to maximize interoperability, both when different network/transport systems are connected through a translator and when an application written under one network/transport system is run atop another or ported to another. I'm not sure what all the implications are, but it might mean that we do want the same port number to show up here as would be used in UDP. > Could the > version bits (2) be traded to distinguish the data from the control > packets? How about a marker bit in the data-header that tells that > there is a control packet after the data packet? These are essentially the same, that is, squeezing a control/data indication into the header somewhere. We can probably find a way to do this, but it might be a source of trouble in that it might lead to control and data being mixed in unintended and non-interoperable ways under IP/UDP as well. > In any above case one > more network layer eg. on the IP/ATM boundary is required. I did not understand this. > Text: > In page 10 where the RTCP packets are being discussed the meaning of > field PT is not clarified, not in this particular packet or for any of > the following packets. Perhaps it would be nice to tell that it > contains the identifier for each packet type? Thanks for pointing out this error, and your other comments. -- Steve ------- From rem-conf-request@es.net Wed Jun 15 03:45:55 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <12382-0@osi-west.es.net>; Wed, 15 Jun 1994 00:45:17 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Wed, 15 Jun 1994 00:45:13 -0700 Posted-Date: Wed 15 Jun 94 00:44:04 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Wed, 15 Jun 94 00:44:05 PDT Date: Wed 15 Jun 94 00:44:04 PDT From: Stephen Casner Subject: Re: RTP in PC-environment / comments to RTP changes To: Jarmo.Molsa@tel.vtt.fi, rem-conf@es.net Message-Id: <771666244.0.CASNER@XFR.ISI.EDU> In-Reply-To: <199403281043.AA11662@tel.vtt.fi> Mail-System-Version: Back in March, during the IETF meeting, Jarmo Molsa wrote the following in response to the request for comments on the preliminary proposal of RTP changes, and I apologize for not replying then. I'll try now: > When reading the RTP-specification, we got the impression, that > application data (e.x. audio data) is handled at very low-level. The > text seems to be rather "sampling-oriented", i.e. the application > program is supposed do some hardware-level things, like collecting > continuously individual samples of audio. Have we got the correct > impression? Not really. For the Sun /dev/audio, one reads a block of samples with a read() call. The timestamp in the revised RTP is a sample counter, but at the transmitter you simply add the block length to the previous counter value to get the new one. > In PC-environment we are using a specific audio/video codec, which > hides all low-level, sample-oriented things. The A/V codec provides > application programming interface (a set of functions for accessing > the codec). The format used by that codec would correspond to some particular RTP "format" or "payload type", perhaps a new one that needs to be defined. The tick rate for the RTP timestamp for that payload type would need to be defined to be something useful in the processing of data for that codec. It could be a 65536Hz clock if that makes sense. Is there a well-defined timing to the data received from the codec? > It seems, that Unix workstations are the primary testing environment > for RTP. It is the most flexible, so that is where the work is done first. > Has anybody done any RTP testing in PC-environment? We hope, > that PC-environment will be properly considered, when specifying > RTP-protocol. Yes, I believe some testing is being done in the PC environment, and I hope that we are considering the requirements of that environment in the protocol design. > Some comments to proposed RTP changes: > -------------------------------------- > > 1. Control and data on separate ports: > At the moment we are experimenting in DOS-environment and > using the PC/TCP-software. This combination limits the number > of descriptors to 20 (including file descriptors and sockets). > If several ports (and thus sockets) should be used, the maximum > descriptor count may cause problems, especially if the application > needs to operate on several files at the same time. For this > reason, the usage of separate ports should be diminished. There are some good reasons for keeping the control and data separate. Since we want PCs and UNIX boxes to interoperate, they would need to use the same rules. It seems like the 20 might not be a problem for applications such as audio + video (2+2), but some other application with lots of separate streams would be a problem. Any chance of getting the limit of 20 increased? Because it seems like you might run into that limit even with 1 port per stream. > 2. Remove Channel ID, put multiplexing into encapsulations > Does the channel ID really add so much overhead, that it should > be removed? It is not so much that the channel ID causes a lot of overhead. Rather, it is that the ILP principle says that multiplexing at several points is bad for performance. > We would like to transmit several RTP-streams (e.g. > audio and video) over a single transport connection (to be able > to get equal transport service). This could partly help in > inter-media synchronization. To put packets from multiple streams into one transport packet required an encapsulation anyway to give the length. In 32 bits we could also hold a "port" number to take the place of the channel ID. -- Steve ------- From rem-conf-request@es.net Wed Jun 15 14:15:23 1994 Received: from wd40.ftp.com by osi-west.es.net via ESnet SMTP service id <14854-0@osi-west.es.net>; Wed, 15 Jun 1994 07:49:18 +0000 Received: from ftp.com by ftp.com ; Wed, 15 Jun 1994 10:49:04 -0400 Received: from mailserv-C.ftp.com by ftp.com ; Wed, 15 Jun 1994 10:49:04 -0400 Received: from chip.slingshot.ftp.com by mailserv-C.ftp.com (5.0/SMI-SVR4) id AA25954; Wed, 15 Jun 94 10:52:40 EDT Date: Wed, 15 Jun 94 10:52:40 EDT Message-Id: <9406151452.AA25954@mailserv-C.ftp.com> To: CASNER@ISI.EDU Subject: Re: RTP in PC-environment / comments to RTP changes From: chip@ftp.com (Chip Sparling) Reply-To: chip@ftp.com Cc: Jarmo.Molsa@tel.vtt.fi, rem-conf@es.net Sender: chip@mailserv-C.ftp.com Repository: mailserv-C.ftp.com, [message accepted at Wed Jun 15 10:52:29 1994] Originating-Client: slingshot.ftp.com Content-Length: 2314 >> Some comments to proposed RTP changes: >> -------------------------------------- >> >> 1. Control and data on separate ports: >> At the moment we are experimenting in DOS-environment and >> using the PC/TCP-software. This combination limits the number >> of descriptors to 20 (including file descriptors and sockets). >> If several ports (and thus sockets) should be used, the maximum >> descriptor count may cause problems, especially if the application >> needs to operate on several files at the same time. For this >> reason, the usage of separate ports should be diminished. > >There are some good reasons for keeping the control and data separate. >Since we want PCs and UNIX boxes to interoperate, they would need to >use the same rules. It seems like the 20 might not be a problem for >applications such as audio + video (2+2), but some other application >with lots of separate streams would be a problem. Any chance of >getting the limit of 20 increased? Because it seems like you might >run into that limit even with 1 port per stream. The default is 20 (and that's what you'll find in the pre-compiled libs), the MAX is currently 32. In the next release the default will be 32 and the MAX will be 64 (late July for PC/TCP Kernel and next week for the Development Kit). For the DOS libraries we do ship our socket source code, so if you change, ~include\4bsd.h to say #define MAXSOCK 32 and ~include\sys\types.h to say #define FD_SETSIZE 32 /* maximum number of DOS file descrs */ #define MAXSELFD 32 /* maxnumber of descrs select() groks */ and your DOS C runtime code to use more than 20 file descriptors, you will have 32 sockets to work with. I can forward the information on changing your C compiler defaults if you'd like too. (That is coming from the engineer that writes the APIs, I'm just a Marketing guy.) If you have any problems, let me know. chip PS I'm working on getting back to all of you that responded to my mail about using PCs. I've been distracted by our pesky customers :-) -- Chip Sparling ftp Software, Inc. Internet: chip@ftp.com 2 High Street (508) 685-4000, fax: (508) 659-6104 North Andover, MA 01845 From rem-conf-request@es.net Wed Jun 15 15:37:53 1994 Received: from Princeton.EDU by osi-west.es.net via ESnet SMTP service id <17401-0@osi-west.es.net>; Wed, 15 Jun 1994 12:36:55 +0000 Received: from ponyexpress.Princeton.EDU by Princeton.EDU (5.65b/2.111/princeton) id AA02176; Wed, 15 Jun 94 15:34:19 -0400 Received: from deepthought.Princeton.EDU by ponyexpress.princeton.edu (5.65c/1.113/newPE) id AA22307; Wed, 15 Jun 1994 15:34:17 -0400 Received: by deepthought.Princeton.EDU (4.1/Phoenix_Cluster_Client) id AA06073; Wed, 15 Jun 94 15:34:17 EDT Message-Id: <9406151934.AA06073@deepthought.Princeton.EDU> To: klemets@paul.rutgers.edu (Anders Klemets) Cc: tengi@Princeton.EDU, rem-conf@es.net Subject: Re: Media on Demand paper In-Reply-To: Your message of Wed, 01 Jun 1994 14:18:08 -0400. <9406011818.AA01734@living.rutgers.edu> X-Mailer: exmh version 1.4zeta 6/10/94 Date: Wed, 15 Jun 1994 15:34:16 EDT From: Christopher Tengi Anders, I tried looking at your paper, but my DNS resolver cannot find www.it.kth.se. In face, I can't even find a SOA record for kth.se (although I do find sunic.sunet.se in the SOA for se). DO you have the paper anywhere else? Thanks, /Chris > I like to bring to your attention that I wrote a paper on the the > design of my WWW-based "Media on Demand" system. It was presented > last week at WWW'94, a USENIX-style conference on WWW. > > The paper is really just a quick hack, like much of my software, but > if you want to check it out, nevertheless, the HTML version is at > http://www.it.kth.se/~klemets/www.html and the postscript is in > http://www.it.kth.se/~klemets/www94/www94.ps > > Should you for some reason be unable to retrieve documents using > WWW, mail me and I'll put it up for ftp. > > Anders From rem-conf-request@es.net Thu Jun 16 04:51:52 1994 Received: from sangam.ncst.ernet.in by osi-west.es.net via ESnet SMTP service id <20722-0@osi-west.es.net>; Thu, 16 Jun 1994 01:51:20 +0000 Received: (from uucp@localhost) by sangam.ncst.ernet.in (8.6.8.1/8.6.6) with UUCP id OAA16831 for rem-conf@es.net; Thu, 16 Jun 1994 14:20:58 +0530 Received: by henna.iitd.ernet.in (4.1/SMI-4.1-MHS-7.0 ) id AA08139; Thu, 16 Jun 94 13:30:10 IST X-Organisation: Indian Institute of Technology, New Delhi. Date: Thu, 16 Jun 1994 13:28:12 +0530 (IST) From: Palepu Srinivas Subject: sd : A query To: rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have the following query about "sd". Suppose I create a session with "sd". Does the advertisement for my session get multicasted directly from my end, or is it being unicasted to some central site from where it is being multicasted? If the latter is what is going on, I want to know the address of this central site. My guess is that the former must be the solution. In which case also, I shall like to know the address and port no. for this "well-known" multicast channel. In either case, I would like to know the message-exchange protocol that is being followed. The objective being that one might want to be able to develop one's own conferencing software, while also using information about other sessions, which will be known more popularly in "sd" format. The answer to this question is not in the FAQ. Thanks in advance. ============================================================================= Srinivas Palepu palepu@henna.iitd.ernet.in Ph: (W) +91-11-686 7431 Deptt of Comp.Sc & Engg Voice Mail +91-11-376 0520 IIT Hauz Khas, N.Delhi-16 Fax +91-11-686 8765 ----------------------------------------------------------------------------- From rem-conf-request@es.net Thu Jun 16 08:06:39 1994 Received: from cs.tut.fi by osi-west.es.net via ESnet SMTP service id <21365-0@osi-west.es.net>; Thu, 16 Jun 1994 05:06:09 +0000 Received: from kaarne.cs.tut.fi (mit@kaarne.cs.tut.fi [130.230.3.2]) by cs.tut.fi (8.6.9/8.6.4) with ESMTP id PAA15934; Thu, 16 Jun 1994 15:07:31 +0300 From: Tsokkinen Mikko Received: (mit@localhost) by kaarne.cs.tut.fi (8.6.8/8.6.4) id PAA03201; Thu, 16 Jun 1994 15:06:05 +0300 Date: Thu, 16 Jun 1994 15:06:05 +0300 Message-Id: <199406161206.PAA03201@kaarne.cs.tut.fi> To: Palepu Srinivas Cc: rem-conf@es.net Subject: sd : A query In-Reply-To: References: Palepu Srinivas writes: > >I have the following query about "sd". > >Suppose I create a session with "sd". Does the advertisement for my >session get multicasted directly from my end, or is it being unicasted to >some central site from where it is being multicasted? >If the latter is what is going on, I want to know the address of this >central site. >My guess is that the former must be the solution. In which case also, I >shall like to know the address and port no. for this "well-known" >multicast channel. >In either case, I would like to know the message-exchange protocol >that is being followed. The objective being that one might want to be able >to develop one's own conferencing software, while also using information >about other sessions, which will be known more popularly in "sd" format. > >The answer to this question is not in the FAQ. Here is the sd-listen program, sd information can be digged up from the source. This might not be the newest version of this program, but should provide enough information. Mikko Tsokkinen Tampere University of Technology Research Assistant - Project FASTER Distributed Multimedia Applications over ATM-Network /* * Program to listen for SD style packets and print out the * announcements. * * This program is experimental and not guarenteed to digest all * SD packets correctly. Since the packet format was reverse * engineered, packets not seen before may not work. * * Tom Pusateri (pusateri@cs.duke.edu) * * * Redistribution and use in source and binary forms, with or without * modification, are permitted without restriction. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED * WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. * * $Id: sd-listen.c,v 1.1 94/01/18 09:35:01 pusateri Exp $ */ #define MULTICAST #include #include #include #include #include #include #include #include #define SD_GROUP 0xe0027fff #define SD_PORT 9876 struct sd_header { u_long unknown1; u_long src; u_short unknown2; char name[1]; }; void dump(buf, buflen) char *buf; int buflen; { int i; printf("Unexpected packet. Dumping...\n"); for (i=0; i\n", argv[0]); exit(1); } if((sock=socket( AF_INET, SOCK_DGRAM, 0 )) < 0) { perror("socket"); exit(1); } imr.imr_multiaddr.s_addr = SD_GROUP; imr.imr_multiaddr.s_addr = htonl(imr.imr_multiaddr.s_addr); imr.imr_interface.s_addr = inet_addr(argv[1]); imr.imr_interface.s_addr = htonl(imr.imr_interface.s_addr); if (setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, &imr, sizeof(struct ip_mreq)) < 0 ) { perror("setsockopt - IP_ADD_MEMBERSHIP"); exit(1); } /* * Use INADDR_ANY if your multicast port doesn't allow * binding to a multicast address. * */ name.sin_family = AF_INET; #ifndef CANT_MCAST_BIND name.sin_addr.s_addr = htonl(SD_GROUP); #else name.sin_addr.s_addr = INADDR_ANY; #endif name.sin_port = htons(SD_PORT); if (bind(sock, &name, sizeof(name))) { perror("bind"); exit(1); } rd = (1 << sock); while (select(sock+1, &rd, 0, 0, 0) > 0) { j = 0; if ((length = recv(sock, (char *) buf, sizeof(buf), 0)) < 0) { perror("recv"); exit(1); } /* print session */ bp = (struct sd_header *) buf; session = bp->name; if ((end=strchr(session, 0x0a)) == NULL) dump(buf, length); *end++ = '\0'; printf("\n%s\n", session); length -= end-buf; i = 0; while (length > 0) { cur = end; switch (*cur) { case 'a': /* print format */ fmt = end+2; if ((end=strchr(fmt, 0x0a)) == NULL) dump(buf, length); *end++ = '\0'; length -= end-cur; break; case 'i': /* print description */ desc = end+2; if ((end=strchr(desc, 0x0a)) == NULL) dump(buf, length); *end++ = '\0'; length -= end-cur; break; case 'o': /* print originator */ orig = end+2; if ((end=strchr(orig, 0x0a)) == NULL) dump(buf, length); *end++ = '\0'; length -= end-cur; break; case 'c': /* print channel */ chan = end+2; if ((end=strchr(chan, 0x0a)) == NULL) dump(buf, length); *end++ = '\0'; length -= end-cur; break; case 'm': /* print media */ media[j] = end+2; if ((end=strchr(media[j++], 0x0a)) == NULL) dump(buf, length); *end++ = '\0'; length -= end-cur; break; default: /* unknown */ unknown = end+2; if ((end=strchr(unknown, 0x0a)) == NULL) dump(buf, length); *end++ = '\0'; length -= end-cur; printf("Warning: unknown option - %s\n", unknown); break; } i++; } printf("%s.\n", desc); sscanf(chan, "%s %d %ld %ld", tmpstr, &ttl, &time1, &time2); printf("@ %s, ttl %d\n", tmpstr, ttl); printf("Media:"); for (i=0; i 0) printf(",\n"); printf(" %s@%d/%d", tmpstr, port1, port2); } printf("\n"); printf("%s\n", fmt); printf("Created by %s\n (%s).\n", orig, inet_ntoa(bp->src)); } close(sock); return(0); } From rem-conf-request@es.net Thu Jun 16 09:43:32 1994 Received: from relay.nswc.navy.mil by osi-west.es.net via ESnet SMTP service id <21649-0@osi-west.es.net>; Thu, 16 Jun 1994 06:43:05 +0000 Received: from sunoco.nswc.navy.mil by relay.nswc.navy.mil (4.1/SMI-4.1) id AA16524; Thu, 16 Jun 94 09:42:56 EDT Received: from vaxless.b35ita.sunoco by sunoco.nswc.navy.mil (5.0/SMI-SVR4) id AA00503; Thu, 16 Jun 1994 09:42:56 +0500 Received: by vaxless.b35ita.sunoco (5.0/SMI-SVR4) id AA06233; Thu, 16 Jun 1994 09:42:42 +0500 Date: Thu, 16 Jun 1994 09:42:42 +0500 From: pirey%sunoco@relay.nswc.navy.mil (Phil Irey) Message-Id: <9406161342.AA06233@vaxless.b35ita.sunoco> To: rem-conf@es.net Subject: Does NV support S-VHS? X-Sun-Charset: US-ASCII Content-Length: 101 Is there a way to select the Super VHS input on a VideoPix or SunVideo board from NV? thanks, phil From rem-conf-request@es.net Thu Jun 16 14:49:15 1994 Received: from sun2.nsfnet-relay.ac.uk by osi-west.es.net via ESnet SMTP service id <23069-0@osi-west.es.net>; Thu, 16 Jun 1994 11:48:40 +0000 Via: uk.ac.edinburgh.festival; Thu, 16 Jun 1994 19:47:15 +0100 Received: from ucs.ed.ac.uk by festival.ed.ac.uk id aa14447; 16 Jun 94 19:47 BST Received: from scorpio.ucs.ed.ac.uk by ucs.ed.ac.uk; Thu, 16 Jun 94 19:47:05 BST Date: Thu, 16 Jun 94 19:47:03 BST Message-Id: <8569.9406161847@scorpio.ucs.ed.ac.uk> From: Graeme Wood Subject: Community Workshop `94 multicast To: rem-conf@es.net Reply-To: Graeme.Wood@edinburgh.ac.uk X-Department: Unix Systems Support, Computing Services X-Organisation: The University of Edinburgh X-Url: "http://www.ucs.ed.ac.uk/~jaw/" X-Phone: +44 (0)31 650 5003 X-Fax: +44 (0)31 650 6552 It is our intention to multicast the following Community workshop of ex-MTS sites to the Internet. The workshop will take place between the 27th June and 1st July. The times of the multicasts are yet to be decided but probably between 0900 GMT+1 and 1700 GMT+1. I would imagine one nv video, vat and whiteboard session will be available. An SD announcement will be made nearer the time. Please let me know if this is going to clash with anything. Graeme Wood PS. For those in the UK it may be possible to put this out on SuperJANET subject to other conference bookings and the conference taking place near a suitable video outlet. Here is the preliminary conference program: > > Community Workshop `94 > > > > Technical Programme > > > > > > The intention is to organise the workshop by creating a number of > > major strands, each of which would > > then have a number of sub-topics which would form the basis of > > individual sessions at the workshop. > > > > In addition we have identified a number of additional, individual, > > topics which will be handled by > > either a single or maybe two sessions. > > > > What we need from YOU is: > > * ideas for new sub-topics > > * offers to lead sessions on sub-topics > > * general comments on the form of the programme > > > > Comments and offers can either be made to the full list or to the > > idividuals named against the strands > > who are co-ordinating the overall structure of their strand. > > > > STRAND > > 1.Security Peter Van Epp(vanepp@sfu.ca) > > > > - Administration sharing the same network > > - the 8lgm advisories > > - bugtrac > > - iss > > - how secure is secure enough? > > - what incidents have the various sites experienced (I expect > > this will be off the record, certainly in terms of our site). > > - network sniffing (are passwords obsolete?) > > - kerberos, smart card authenticators, PC clients. > > - Administrative computing over the campus backbone (which is > > what is driving kerberos and to some extent ATM at SFU). > > - Firewalls, how usefull? Performace problems? > > - open access vs knowing who is doing what? > > - controlling offensive material? > > - Using digital signatures now? > > - Inventory Collection (Do you know what is where?) > > > > > > > > 2. High Speed Comms Bill Baines(bill@sfu.ca) > > > > Is ATM the future? Local, Metropolitan or wide area usage? > > - there is a research ATM test bed being constructed between SFU > > and UBC > > - SFU impression and intentions on ATM vendors. > > > > Non ATM networking > > > > - FDDI has its time come and gone (we (SFU) think so)? > > - Ethernet chip bugs, are they biting you? > > - router experiences (ours has been poor, which sparked the first > > item) > > - load experiences, and futures (with Mosaic and WWW to chew more > > bandwidth on > > the wide area). > > - fast ethernet > > - Fibrechannel > > > > Low Cost remote access to the campus > > - Relevance of ISDN to campus access > > > > 3. E-Mail Kari Gluski(kari@umich.edu) > > > > * Should User Interfaces be stand-alone or part of a co-ordinated > > suite? > > > > * What software for large scale mail hubs? > > > > * e-mail security issues - PGP, and other encrypting mail systems , > > the legal issues for the > > US and Canada, digital signatures > > > > * Directory Services for e-mail addressing and forwarding -- setting > > up > > campus-wide services, integrating different mail systems' > > directories > > > > * LAN-based e-mail services -- who is going in this direction, how > > are > > they handling remote dial-in access issues, are services scaling > > well? > > > > * PowerTalk support on MACs. Integration of PowerTalk to Campus > > Directories > > 4. Distributed Services Ian Simpson(Ian.Simpson@ualberta.ca) > > - OSF/DCE Developments > > - Unix backup - Peter Van Epp > > - will NFS V3 over take DCE/DFS? > > - SFU experiences (eg Bandwidth consequences) with Arcserve for > > Novell backup > > - Macs, PCs and Novell are winning the war of the desktop at SFU > > - Support of Unix on the desktop > > - Unixes, (i.e Linux, FreeBSD, NetBSD, BSDI) that come with source > > and run on PCs. > > - Mainframe like fees for stats packages on more powerful Unix > > machines > > - Networked CD-ROMS - problems, solutions? > > 5. Networked Information Services ? > > > > CWIS issues > > WWW vs Gopher > > Handling huge mailing lists > > Use of such technologies to hold the Community together > > > > 6. Strategies & Structures Richard Field(R.Field@ed.ac.uk) > > Futures, Quality > > Will the Commercial world dictate the future > > > > - "Information superhighway" initiatives - will they change the way > > the Internet is run? > > - Leasing machines instead of buying (this has worked well for SFU) > > - PowerPCs, can one machine replace both Macs and PCs in a lab and > > look like either when > > required? > > Sessions > > > > MTS > > - Lessons in migrating off, sustaining legacy services. > > > > MM - How to expliot the available technology, Teaching and Learning > > Opportunities > > > > Invited Speakers, > > ? Computer created music (Peter Nelson) > > ? Libraries & Computing Services - Convergence ? (Michael > > Breakes) > > > > User Interactions > > Handling user queries > > Tracking problems > > > ---- End of forwarded text ---- > ---- End of forwarded text ---- From rem-conf-request@es.net Thu Jun 16 15:19:19 1994 Received: from aeffle.Stanford.EDU by osi-west.es.net via ESnet SMTP service id <23270-0@osi-west.es.net>; Thu, 16 Jun 1994 12:18:46 +0000 Received: (from mosedale@localhost) by aeffle.Stanford.EDU (8.6.8.1/8.6.6) id MAA27143 for rem-conf@es.net; Thu, 16 Jun 1994 12:20:20 -0700 From: Dan Mosedale Message-Id: <199406161920.MAA27143@aeffle.Stanford.EDU> Subject: Collected rem-conf wisdom & where 2 announce To: rem-conf@es.net Date: Thu, 16 Jun 1994 12:20:19 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1489 I'm planning to put a conference on the MBONE in a few months (to-be-announced shortly), and I'd be interested in hearing the rem-conf list's collective wisdom about logistics for this sort of thing. What sort of gotchas have you experienced in putting conferences on the net in the past, and how did you overcome them? Some questions of particular interest include: - has anyone calculated the magic formula: given an overhead projector at distance P from a screen of size S, and given a camera at distance C from the screen, what is the mininum font size that speakers should use on their overheads to be legible over vat video? - what are the various problems associated with accepting audio questions from the net and broadcasting them into the audio system of the conference room? - given that many folks seem to be announcing their conferences on the mbone list rather than rem-conf lately, is it now acceptable to post announcements both places so that folks who don't know about rem-conf will see them? - is there a good way to avoid the phenomenon where the camera focused on the overhead screen sees the screen being much brighter in the center (because of the overhead projector bulb)? - why do most conferences have two separate nv sessions for slides and speaker video -- why not just have a single nv window with two video sources? - any other tips.... Thanks, Dan From rem-conf-request@es.net Thu Jun 16 15:35:21 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <23363-0@osi-west.es.net>; Thu, 16 Jun 1994 12:34:52 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14464(4)>; Thu, 16 Jun 1994 12:34:41 PDT Received: from localhost by ecco.parc.xerox.com with SMTP id <16150>; Thu, 16 Jun 1994 12:34:30 -0700 To: pirey%sunoco@relay.nswc.navy.mil (Phil Irey) cc: rem-conf@es.net Subject: Re: Does NV support S-VHS? In-reply-to: Your message of "Wed, 15 Jun 94 21:42:42 PDT." <9406161342.AA06233@vaxless.b35ita.sunoco> X-Mailer: exmh version 1.4zeta 6/10/94 Date: Thu, 16 Jun 1994 12:34:19 PDT Sender: Ron Frederick From: Ron Frederick Message-Id: <94Jun16.123430pdt.16150@ecco.parc.xerox.com> In message <9406161342.AA06233@vaxless.b35ita.sunoco> you write: > Is there a way to select the Super VHS input on a VideoPix > or SunVideo board from NV? > Not in nv 3.2, but there will be in nv 3.3 (and is currently in 3.3alpha). You go to the "Panels..." menu and tell it to show the grabber control panel. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Thu Jun 16 16:08:15 1994 Received: from ki1.chemie.fu-berlin.de by osi-west.es.net via ESnet SMTP service id <23476-0@osi-west.es.net>; Thu, 16 Jun 1994 13:07:26 +0000 Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from lutzifer.hanse.de (193.174.9.9) with smtp id ; Thu, 16 Jun 94 22:06 MEST Received: from drdhh.hanse.de by lutzifer.hanse.de with UUCP id AA20418 (5.65c/IDA-1.4.4 for rem-conf@es.net); Thu, 16 Jun 1994 21:43:47 +0200 Received: from ponton.UUCP by drdhh.hanse.de with UUCP id AA12873 (5.67a8/Island-3.2-1.53-LOG for rem-conf@es.net); Thu, 16 Jun 1994 18:52:21 +0200 Received: by ponton.hanse.de (1.65/waf) via UUCP; Thu, 16 Jun 94 16:45:46 CEST for rem-conf@es.net To: rem-conf@es.net Subject: transmission request From: kate@ponton.hanse.de (Katharina Baumann) Reply-To: kate@ponton.hanse.de Message-Id: Date: Thu, 16 Jun 94 16:43:06 CEST Organization: Ponton European Media Art Lab * Announcement of an MBone transmission: we would like to transmit parts of our project Piazza virtuale: Service Area a.i.via MBone. As it's considered good taste to ask the MBone-community for acceptance, I would like to do this hereby. If somebody does not agree, please let me know. The transmissions will take place from 21th to 26th of June, three times a day for about 20 minutes during the tv broadcast via 3sat. Scheduled dates are: Tuesday, 06/21/94: 17:00-17:15, 19:00-19:20 and 23:00-00:20 Wednesday, 06/22/94 17:00-17:15, 19:20-19:30 Thursday, 06/23/94 02:10-02:30, 17:00-17:15, 19:20-19:30 Friday, 06/24/94 01:40-02:00, 17:00-17:15, 19:20-19:30 Saturday 06/25/94 02:00-02:20, 14:50-15:15, 19:00-19:15 Sunday, 06/26/94 02:20-02:40 all dates in CET. Everyone with access is invited to take part of our project. A short description of Service Area a.i. is included below, if you'd like to have additional information, please drop me a line. Kate Baumann PONTON EUROPEAN MEDIA ART LAB -----cut here -> * Service Area a.i. - The Project * Piazza virtuale: Service Area a.i. The coming media technology and its influence on the relation of public and private space has to be experienced in a new way. It needs a new comment. The enhancement of the communication networks offers the possibility to send pictures, sound, and text around the world at a maximum speed. The growth of technical facilities does not necessarily imply the quality of culture. Cafeterias and markets are the locations where in former centuries most of the cultural life took place. People met there for business, to exchange opinions or for amusement. The society today is characterized by the lack of public space. With the rise of the information age the public is urging into the private sphere of everybody. Service Area a.i. is the installation of a virtual, telematic world that offers its participants at home a multimedial access by the networks. Service Area a.i. is a virtual space within the electronical network.The aim is not to define a machine as the end in itself, but to work out interfaces, in which one can encounter people by the use of electronic media. The participants of Service Area a.i. meet in a space that gives them the possibility for mutual as well as for individual experiences. Service Area a.i. leaves room for people to communicate with each other and to each other. Service Area a.i. does not promote technology for its own sake, but people with their communicative capacities, cognitive actions and creative expressions. The Participation in Service Area a.i. Service Area a.i. is online 24 hours a day and accessible from everywhere. The audience in front of their screens can dial themselves in and participate in Service Area a.i. directly during the broadcast. Installing Service Area a.i. Service Area a.i. is more than a telematic project that is visualized on screens of all kind. At the Bruckner-Haus in Linz there is an entry point installed. Here Visitors of the Ars Electronica are given the opportunity to enter the virtual world. The Poets and Service Area a.i. The poet interprets and transcends society in his language and thus is able to build a bridge between Service Area a.i. and the audience that can so follow the original process of the virtual world. Why Service Area a.i.? Television as we know it today will not exist for long any more. The question of new media is at the same time the question of their contents, as interactive channels can be more than the highway for teleshopping or war-simulating games. Service Area a.i. is a cultural sketch for the formation of multimedia-networks. It consists of a communication model in which the relation between the sender and the receiver compared to the well known mass media is thoroughly changed. Television broadcasts in the context of Service Area a.i. The live TV transmission is a window into the electronic world of Service Area a.i.. The window allows an overview of the telematic landscape and reflects the events. During the show poets are interfacing their personal experience with the window open to the outside world - the TV. Networking scheme of Piazza virtuale: Service Area a.i. Three locations are involved in the realisation of Service Area a.i.: Ponton in Hannover, where the communication links come together and are processed by computers; the ZDF/3sat studio in Mainz where the TV program is being broadcasted via cable and satellite; and the interactive installation at the Ars electronica in Linz, where a 3D-projection of the network activity is visible. Participants can access Service Area a.i. on two main roads. The first access channel is the telephone system using different media. People with AVIS and a video camera can send pictures, faces, and gestures to Service Area a.i. AVIS is a simple, low-cost video digitizing hardware developed by Ponton that can be bought by the participants. Service Area a.i. is capable of handling up to 200 simultaneous participants 24 hours a day. It will start working about one month ahead of Ars electronica and will be continued afterwards. During the five days of Ars electronica there will be three daily TV broadcasts. -- kate@ponton.hanse.de * Katharina Baumann * Ponton European Media Art Lab From rem-conf-request@es.net Thu Jun 16 16:21:58 1994 Received: from 163.121.2.3 by osi-west.es.net via ESnet SMTP service id <23553-0@osi-west.es.net>; Thu, 16 Jun 1994 13:21:08 +0000 Received: by ritsec.com.eg (5.57/Ultrix3.0-C) id AA21137; Thu, 16 Jun 94 20:08:31 -0400 Date: Thu, 16 Jun 94 20:08:31 -0400 From: radel@ritsec.com.eg (Rasha Adel) Message-Id: <9406170008.AA21137@ritsec.com.eg> To: rem-conf@es.net Subject: receiving video frames Is there any way to receive a unicasted frame at a very slow rate by asking the sender to send at a very slow rate so not to congest the link. it will be unicasted not multicasted. thank you in advance. Rasha From rem-conf-request@es.net Thu Jun 16 16:35:24 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <23572-0@osi-west.es.net>; Thu, 16 Jun 1994 13:34:27 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Thu, 16 Jun 1994 13:34:19 -0700 Posted-Date: Thu 16 Jun 94 13:33:18 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Thu, 16 Jun 94 13:33:19 PDT Date: Thu 16 Jun 94 13:33:18 PDT From: Stephen Casner Subject: Comments on RTPv2? To: rem-conf@es.net Message-Id: <771798798.0.CASNER@XFR.ISI.EDU> Mail-System-Version: To the Audio/Video Transport working group: Perhaps I should take it as a good sign that people are not complaining about the proposed revision of RTP (v2), but I was hoping for more discussion of the open issues. Even if you think all the choices are correct as they stand, I'd appreciate a note saying so. To repeat, the memo describing the revisions is available from ftp.isi.edu:mbone/avt/rtpv2.txt -- Steve ------- From rem-conf-request@es.net Thu Jun 16 17:35:05 1994 Received: from ki1.chemie.fu-berlin.de by osi-west.es.net via ESnet SMTP service id <23856-0@osi-west.es.net>; Thu, 16 Jun 1994 14:33:45 +0000 Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from lutzifer.hanse.de (193.174.9.9) with smtp id ; Thu, 16 Jun 94 23:33 MEST Received: from drdhh.hanse.de by lutzifer.hanse.de with UUCP id AA24507 (5.65c/IDA-1.4.4 for rem-conf@es.net); Thu, 16 Jun 1994 23:30:19 +0200 Received: from ponton.UUCP by drdhh.hanse.de with UUCP id AA14016 (5.67a8/Island-3.2-1.53-LOG for rem-conf@es.net); Thu, 16 Jun 1994 20:02:18 +0200 Received: by ponton.hanse.de (1.65/waf) via UUCP; Thu, 16 Jun 94 16:45:46 CEST for rem-conf@es.net To: rem-conf@es.net Subject: transmission request From: kate@ponton.hanse.de (Katharina Baumann) Reply-To: kate@ponton.hanse.de Message-Id: Date: Thu, 16 Jun 94 16:43:06 CEST Organization: Ponton European Media Art Lab * Announcement of an MBone transmission: we would like to transmit parts of our project Piazza virtuale: Service Area a.i.via MBone. As it's considered good taste to ask the MBone-community for acceptance, I would like to do this hereby. If somebody does not agree, please let me know. The transmissions will take place from 21th to 26th of June, three times a day for about 20 minutes during the tv broadcast via 3sat. Scheduled dates are: Tuesday, 06/21/94: 17:00-17:15, 19:00-19:20 and 23:00-00:20 Wednesday, 06/22/94 17:00-17:15, 19:20-19:30 Thursday, 06/23/94 02:10-02:30, 17:00-17:15, 19:20-19:30 Friday, 06/24/94 01:40-02:00, 17:00-17:15, 19:20-19:30 Saturday 06/25/94 02:00-02:20, 14:50-15:15, 19:00-19:15 Sunday, 06/26/94 02:20-02:40 all dates in CET. Everyone with access is invited to take part of our project. A short description of Service Area a.i. is included below, if you'd like to have additional information, please drop me a line. Kate Baumann PONTON EUROPEAN MEDIA ART LAB -----cut here -> * Service Area a.i. - The Project * Piazza virtuale: Service Area a.i. The coming media technology and its influence on the relation of public and private space has to be experienced in a new way. It needs a new comment. The enhancement of the communication networks offers the possibility to send pictures, sound, and text around the world at a maximum speed. The growth of technical facilities does not necessarily imply the quality of culture. Cafeterias and markets are the locations where in former centuries most of the cultural life took place. People met there for business, to exchange opinions or for amusement. The society today is characterized by the lack of public space. With the rise of the information age the public is urging into the private sphere of everybody. Service Area a.i. is the installation of a virtual, telematic world that offers its participants at home a multimedial access by the networks. Service Area a.i. is a virtual space within the electronical network.The aim is not to define a machine as the end in itself, but to work out interfaces, in which one can encounter people by the use of electronic media. The participants of Service Area a.i. meet in a space that gives them the possibility for mutual as well as for individual experiences. Service Area a.i. leaves room for people to communicate with each other and to each other. Service Area a.i. does not promote technology for its own sake, but people with their communicative capacities, cognitive actions and creative expressions. The Participation in Service Area a.i. Service Area a.i. is online 24 hours a day and accessible from everywhere. The audience in front of their screens can dial themselves in and participate in Service Area a.i. directly during the broadcast. Installing Service Area a.i. Service Area a.i. is more than a telematic project that is visualized on screens of all kind. At the Bruckner-Haus in Linz there is an entry point installed. Here Visitors of the Ars Electronica are given the opportunity to enter the virtual world. The Poets and Service Area a.i. The poet interprets and transcends society in his language and thus is able to build a bridge between Service Area a.i. and the audience that can so follow the original process of the virtual world. Why Service Area a.i.? Television as we know it today will not exist for long any more. The question of new media is at the same time the question of their contents, as interactive channels can be more than the highway for teleshopping or war-simulating games. Service Area a.i. is a cultural sketch for the formation of multimedia-networks. It consists of a communication model in which the relation between the sender and the receiver compared to the well known mass media is thoroughly changed. Television broadcasts in the context of Service Area a.i. The live TV transmission is a window into the electronic world of Service Area a.i.. The window allows an overview of the telematic landscape and reflects the events. During the show poets are interfacing their personal experience with the window open to the outside world - the TV. Networking scheme of Piazza virtuale: Service Area a.i. Three locations are involved in the realisation of Service Area a.i.: Ponton in Hannover, where the communication links come together and are processed by computers; the ZDF/3sat studio in Mainz where the TV program is being broadcasted via cable and satellite; and the interactive installation at the Ars electronica in Linz, where a 3D-projection of the network activity is visible. Participants can access Service Area a.i. on two main roads. The first access channel is the telephone system using different media. People with AVIS and a video camera can send pictures, faces, and gestures to Service Area a.i. AVIS is a simple, low-cost video digitizing hardware developed by Ponton that can be bought by the participants. Service Area a.i. is capable of handling up to 200 simultaneous participants 24 hours a day. It will start working about one month ahead of Ars electronica and will be continued afterwards. During the five days of Ars electronica there will be three daily TV broadcasts. -- kate@ponton.hanse.de * Katharina Baumann * Ponton European Media Art Lab From rem-conf-request@es.net Thu Jun 16 20:56:52 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <24584-0@osi-west.es.net>; Thu, 16 Jun 1994 17:56:22 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Thu, 16 Jun 1994 17:56:19 -0700 Posted-Date: Thu 16 Jun 94 17:55:17 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Thu, 16 Jun 94 17:55:18 PDT Date: Thu 16 Jun 94 17:55:17 PDT From: Stephen Casner Subject: Re: Collected rem-conf wisdom & where 2 announce To: mosedale@genome.stanford.edu, rem-conf@es.net Message-Id: <771814517.0.CASNER@XFR.ISI.EDU> In-Reply-To: <199406161920.MAA27143@aeffle.Stanford.EDU> Mail-System-Version: A few quick answers: > - has anyone calculated the magic formula: given an overhead > projector at distance P from a screen of size S, and given a > camera at distance C from the screen, what is the mininum font > size that speakers should use on their overheads to be legible > over vat video? Given a zoom lens, none of those factors matter. What does matter is how many characters you try to put into the viewable area, and for that, my answer is you should use 24 point. (In fact, I have adopted that practice without regard to the use of video.) The most common failure is not zooming in tight enough. It's better to clip a little bit of text and have the rest visible than to zoom back so you see the whole screen but can't read any of the text. > - what are the various problems associated with accepting audio > questions from the net and broadcasting them into the audio > system of the conference room? If you use the "Net mutes mike" option on whatever output port you connect to the room audio system, it works reasonably well. The biggest problem is making sure you have a clean audio signal at the right level going both ways. If you have access to the room ahead of time and can test all of this, you should be able to make it work fine. > - given that many folks seem to be announcing their conferences on > the mbone list rather than rem-conf lately, is it now acceptable > to post announcements both places so that folks who don't know > about rem-conf will see them? I still suggest that rem-conf is the right place, assuming that most people on mbone are also on rem-conf. However, since announcements tend to be isolated messages, rather than the start of a discourse, there's less harm done when an anouncement goes to both. > - is there a good way to avoid the phenomenon where the camera > focused on the overhead screen sees the screen being much > brighter in the center (because of the overhead projector bulb)? Get a better projector? > - why do most conferences have two separate nv sessions for slides > and speaker video -- why not just have a single nv window with > two video sources? Good question. One possible reason is that in areas where multicast pruning is in use, if only one channel is selected in some part of the tree then the traffic for the other channel won't be delivered in that part of the tree. -- Steve ------- From rem-conf-request@es.net Thu Jun 16 22:10:05 1994 Received: from ibminet.awdpa.ibm.com by osi-west.es.net via ESnet SMTP service id <24716-0@osi-west.es.net>; Thu, 16 Jun 1994 19:09:31 +0000 Received: by ibminet.awdpa.ibm.com (5.61/1.15) id AA25958; Thu, 16 Jun 94 19:16:32 -0700 Received: by ibmpa.awdpa.ibm.com (5.65b(em1)/2.06) id AA25889; Thu, 16 Jun 94 19:07:51 -0700 Received: from taurus.cs.nps.navy.mil by ibminet.awdpa.ibm.com (5.61/1.15) id AA25752; Thu, 16 Jun 94 19:10:49 -0700 Received: from trouble.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA27668; Thu, 16 Jun 94 19:05:29 PDT Received: by trouble.cs.nps.navy.mil (931110.SGI/911001.SGI) for @taurus.cs.nps.navy.mil:rem-conf%es.net@ibmpa.awdpa.ibm.com id AA26488; Thu, 16 Jun 94 19:05:28 -0700 From: Your VE info source Message-Id: <9406161905.ZM26476@trouble.cs.nps.navy.mil> Date: Thu, 16 Jun 1994 19:05:27 -0700 X-Mailer: Z-Mail (3.1b.0 09feb94 MediaMail) To: rem-conf%es.net@ibmpa.awdpa.ibm.com Subject: PRESENCE: Call for Cover Photos Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 PRESENCE - Call for Cover Photos PRESENCE, the premier journal of teleoperation and virtual environments, is looking for cover photos for its upcoming issues. We desire color 35mm slides depicting virtual environments and teleoperation. These slides can be of VE and teleoperation apparatus, of computer displays of your virtual environment or any other VE/teleoperation-relevant image. Include with your images an extended caption describing your image - 7 to 8 sentences - and any credits required for the image. We are particularly interested in images related to the themes of upcoming special issues: Volume 3.1 is the Pacific Rim special issue. --> *** We need a good, high quality cover image for this special issue immediately (by 30 June 94). Volume 3.2 The Application of Virtual Environments to Architecture, Building and Large Structure Design --> We need cover images for this special issue by 15 July 94. Volume 3.3 is the special issue on VE and Teleoperation for Disability --> We need cover images by 15 July 94. Volume 3.4 is the first of two special issues on Networked Virtual Environments and Teleoperation. --> We need cover images by 15 August 94. Volume 4.1 is the second of two special issues on Networked Virtual Environments and Teleoperation. --> We need cover images by 15 September 94. Send your 35mm slides to: Doug Allen, Assistant Managing Editor, PRESENCE MIT 50 Vassar Avenue Room 36-709 Cambridge, MA 02139-4307 (617) 253-8500 Email: presence@cbgrle.mit.edu From rem-conf-request@es.net Fri Jun 17 04:05:53 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <25664-0@osi-west.es.net>; Fri, 17 Jun 1994 01:05:17 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 17 Jun 1994 09:04:51 +0100 To: Stephen Casner cc: rem-conf@es.net Subject: Re: Comments on RTPv2? In-reply-to: Your message of "Thu, 16 Jun 94 13:33:18 PDT." <771798798.0.CASNER@XFR.ISI.EDU> Date: Fri, 17 Jun 94 09:04:48 +0100 From: Jon Crowcroft >Perhaps I should take it as a good sign that people are not >complaining about the proposed revision of RTP (v2), but I was hoping >for more discussion of the open issues. Even if you think all the >choices are correct as they stand, I'd appreciate a note saying so. Steve they are all at INET this week maybe re-ping them next week... jon From rem-conf-request@es.net Fri Jun 17 10:57:26 1994 Received: from fnal.fnal.gov by osi-west.es.net via ESnet SMTP service id <27092-0@osi-west.es.net>; Fri, 17 Jun 1994 07:56:59 +0000 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HDN7VSKW1C006BTW@FNAL.FNAL.GOV>; Fri, 17 Jun 1994 09:56:40 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA29661; Fri, 17 Jun 94 09:56:27 CDT Date: Fri, 17 Jun 1994 09:56:27 -0500 From: Matt Crawford Subject: how long until pruning is prevalent in the US? To: rem-conf@es.net Message-id: <9406171456.AA29661@munin.fnal.gov> Content-transfer-encoding: 7BIT Does anyone have good idea when we could expect some form of multicast pruning to be prevalent in the US portions of the mbone? We at Fermilab anticipate the collider experiments multicasting their data to their members' home institutions. This would amount to about 200kb/s, 12 hours a day, every day. Maybe not today, maybe not tomorrow, but someday soon and for the rest of the run. I know we have other options, such as setting up private tunnels, but that is clearly sub-optimal. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From rem-conf-request@es.net Fri Jun 17 22:16:42 1994 Received: from nic.funet.fi by osi-west.es.net via ESnet SMTP service id <29168-0@osi-west.es.net>; Fri, 17 Jun 1994 19:16:04 +0000 Received: by nic.funet.fi id <92178-4>; Sat, 18 Jun 1994 05:15:58 +0300 From: Matti Aarnio To: rem-conf@es.net Subject: Multicast kernel 3.x on Sun Solaris ? Message-Id: <94Jun18.051558eet_dst.92178-4@nic.funet.fi> Date: Sat, 18 Jun 1994 05:15:50 +0300 Hello, I have now spent a day (and most of the next night) to learn all kinds of things about how pruning works, but I have been unable to kludge around the Solaris 2.3 kernel to get the transport stabile. I am able to create pruning effect, but it prunes all until next time around there happens a local IGMP_MEMBERSHIP_QUERY, which restores all of the actively used channels. (and grafts them) ("join driven" approac.. ) I do have a feeling that the upstream server will push me whatever it can if I don't send a prune for it explicitely, and I hardly can know what to prune when I can't get report for unrouted datagrams from the kernel. The problem is, of course on the totally different kernel interface in between these two versions, and especially on a way how the router gets information about incoming but unrouted datagrams. I have played with some ideas of doing the missing things with pfbuf(7), but that is a kludge if I have ever seen one.. So, anybody out there with: - Solaris 2.3 sources ? - time for doing the port ? - time for debugging it ? (For those who wonder why I can't do it, the reason is that it needs kernel sources to create a new /kernel/drv/ip :-( ) /Matti Aarnio From rem-conf-request@es.net Sat Jun 18 13:50:49 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <01046-0@osi-west.es.net>; Sat, 18 Jun 1994 10:50:20 +0000 Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 18 Jun 1994 18:50:07 +0100 To: rem-conf@es.net Subject: MICE International Seminar: June 21, 1994. Date: Sat, 18 Jun 94 18:50:03 +0100 From: Gordon Joly At 13:00 GMT/UTC, Professor Lawrence A. Rowe (EECS at Berkeley) will speak on "The Berkeley Distributed Video-on-Demand." An announcement will be made in "sd" on the previous day. Abstract. - ----------- The design and implementation of the Berkeley Distributed Video-on-Demand system will be described. The system is designed to store thousands of hours of video material that users can play without having to know the details of where it is located or how to play it. A three-level storage architecture is required because this amount of video is much too large to store on magnetic disks (e.g., 0.5 GB/hour). Videos are stored permanently on tertiary storage devices that are managed by archive servers. Video file servers (VFS) manage a cache of video objects on magnetic disks that can be played by applications running on client workstations. Applications issue requests to play a video. The system locates and plays the video if it is on one of the VFS's. Otherwise, a request is entered to load it from the appropriate archive. A metadata database is maintained by each archive server that contains indexes into the videos managed by that archive. This database can be queried by a user who wants to find a particular video (e.g., a course lecture on LR parser table construction). We have built a prototype system that manages over 12 GBytes of data, and we are digitizing and indexing almost two hours of material a week. This talk will present the design and implementation of this system and discuss current research problems on which we are working. - ----------- In general, information on the MICE seminars is kept up to date in the WWW at URL http://www.cs.ucl.ac.uk/mice/seminars/ which should also contain abstracts of future talks. Gordon Joly Phone +44 71 380 7934 FAX +44 71 387 1397 Email G.Joly@cs.ucl.ac.uk Comp Sci, University College, London, Gower Street, LONDON WC1E 6BT XXX YYY WWW & http://www.cs.ucl.ac.uk/mice/gjoly.html & WWW YYY XXX From rem-conf-request@es.net Sun Jun 19 07:00:23 1994 Received: from 163.121.2.3 by osi-west.es.net via ESnet SMTP service id <03067-0@osi-west.es.net>; Sun, 19 Jun 1994 03:59:45 +0000 Received: by ritsec.com.eg (5.57/Ultrix3.0-C) id AA00849; Sun, 19 Jun 94 13:03:02 -0400 Date: Sun, 19 Jun 94 13:03:02 -0400 From: radel@ritsec.com.eg (Rasha Adel) Message-Id: <9406191703.AA00849@ritsec.com.eg> To: rem-conf@es.net Subject: call for papers From : Rasha Morgan E-Mail address : radel@ritsec.com.eg Tel : 202 - 3650850 address : 58 el-manial st. app 44, el manial , Cairo , Egypt. subject: invitation for participation in the Interanational Conference of information technology And Socio Economic Development : Challanges and Opportunities. To be held on : Jan ,9- 11 th , 1995. At : Marriott Hotel, Cairo, Egypt. Dear Madam/Sir : you are cordially invited to provide a demonstration for any of your (or your company ) software or products related to the above subjects. Papers and documentations are also wellcomed . For more information please contact Rasha Moragn at the above address. Thank you in advance. From rem-conf-request@es.net Sun Jun 19 11:40:27 1994 Received: from RUTGERS.EDU by osi-west.es.net via ESnet SMTP service id <03443-0@osi-west.es.net>; Sun, 19 Jun 1994 08:39:56 +0000 Received: by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12555; Sun, 19 Jun 94 11:39:54 EDT To: ru-comp-dev-ietf-rem-conf@rutgers.edu Path: rutgers!isi.edu!CASNER From: CASNER@isi.edu (Stephen Casner) Newsgroups: ru.comp.dev.ietf.rem-conf Subject: Re: Comments requested: RTP version 2 Message-Id: <771663281.0.CASNER@XFR.ISI.EDU> Date: 15 Jun 94 06:54:41 GMT References: <199406141403.RAA21870@kaarne.cs.tut.fi> Sender: thayes@rutgers.edu Lines: 86 Mikko Tsokkinen wrote: > RTCP FMT packet: The issue of how to use the payload-type field values > is very problematic. Actually the issues related to format fields > should be specified in some sort of session management protocol. The > number of bits reserved for payload type will not be enough for all > different formats, due to very large number of possible combinations > of different encodings eg. bits/sample, sampling rate, television > system etc. I'm in a favour of specifying few defined formats and > leaving several non-assigned numbers that can be dynamically allocated > depending on the application. The predefined formats should be chosen > so that they are the most common formats eg. the ITU-T G-series for > audio and ISO/ITU-T formats for video. The application specific > formats should be binded for that session only using the FMT packets. In the previous specification, with a 6-bit "format" field, we specified that half the space was for predefined formats and half was for dynamically defined formats. The predefined ones included some of the ITU-T G-series for audio, plus the formats we are actively using in vat. Additional formats could either be defined in the higher-level session protocol (e.g., a session directory could give the type code and the corresponding parameters to the application), or via the FMT option/packet. So, I think we are in agreement. The open question is whether the session directory method is sufficient, and therefore the FMT packet should be removed. > Separate data and control: The idea of separate ports for control and > data is good. However the similar problem of allocating of 2 > connections in ST-II is also present in ATM-network. In my opinion > encapsulation of some sort is required in these connection oriented > networks. 16 bit pre-header (=UDP/TCP port number) could be used to > transport the data to different ports in the receiver. 16 bits won't work well because of alignment. The previous spec defined a framing encapsulation that could be included by profile to allow packets from multiple streams to be packaged in one lower-layer packet, where the "Channel ID" provided the multiplexing. That encapsulation was simply a 32-bit length, even though 16 bits of length is enough. Since the "Channel ID" has been removed, we could modify the encapsulation to take care of both functions together: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | port | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Here this port number would not strictly be a UDP/TCP port number, but would serve a similar multiplexing function. Control and data could be indicated by separate port numbers, as they would be with UDP. A key concern to consider: We want to maximize interoperability, both when different network/transport systems are connected through a translator and when an application written under one network/transport system is run atop another or ported to another. I'm not sure what all the implications are, but it might mean that we do want the same port number to show up here as would be used in UDP. > Could the > version bits (2) be traded to distinguish the data from the control > packets? How about a marker bit in the data-header that tells that > there is a control packet after the data packet? These are essentially the same, that is, squeezing a control/data indication into the header somewhere. We can probably find a way to do this, but it might be a source of trouble in that it might lead to control and data being mixed in unintended and non-interoperable ways under IP/UDP as well. > In any above case one > more network layer eg. on the IP/ATM boundary is required. I did not understand this. > Text: > In page 10 where the RTCP packets are being discussed the meaning of > field PT is not clarified, not in this particular packet or for any of > the following packets. Perhaps it would be nice to tell that it > contains the identifier for each packet type? Thanks for pointing out this error, and your other comments. -- Steve ------- From rem-conf-request@es.net Sun Jun 19 11:40:54 1994 Received: from RUTGERS.EDU by osi-west.es.net via ESnet SMTP service id <03447-0@osi-west.es.net>; Sun, 19 Jun 1994 08:39:59 +0000 Received: by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12569; Sun, 19 Jun 94 11:39:56 EDT To: ru-comp-dev-ietf-rem-conf@rutgers.edu Path: rutgers!isi.edu!CASNER From: CASNER@isi.edu (Stephen Casner) Newsgroups: ru.comp.dev.ietf.rem-conf Subject: Re: RTP in PC-environment / comments to RTP changes Message-Id: <771666244.0.CASNER@XFR.ISI.EDU> Date: 15 Jun 94 07:44:04 GMT References: <199403281043.AA11662@tel.vtt.fi> Sender: thayes@rutgers.edu Lines: 81 Back in March, during the IETF meeting, Jarmo Molsa wrote the following in response to the request for comments on the preliminary proposal of RTP changes, and I apologize for not replying then. I'll try now: > When reading the RTP-specification, we got the impression, that > application data (e.x. audio data) is handled at very low-level. The > text seems to be rather "sampling-oriented", i.e. the application > program is supposed do some hardware-level things, like collecting > continuously individual samples of audio. Have we got the correct > impression? Not really. For the Sun /dev/audio, one reads a block of samples with a read() call. The timestamp in the revised RTP is a sample counter, but at the transmitter you simply add the block length to the previous counter value to get the new one. > In PC-environment we are using a specific audio/video codec, which > hides all low-level, sample-oriented things. The A/V codec provides > application programming interface (a set of functions for accessing > the codec). The format used by that codec would correspond to some particular RTP "format" or "payload type", perhaps a new one that needs to be defined. The tick rate for the RTP timestamp for that payload type would need to be defined to be something useful in the processing of data for that codec. It could be a 65536Hz clock if that makes sense. Is there a well-defined timing to the data received from the codec? > It seems, that Unix workstations are the primary testing environment > for RTP. It is the most flexible, so that is where the work is done first. > Has anybody done any RTP testing in PC-environment? We hope, > that PC-environment will be properly considered, when specifying > RTP-protocol. Yes, I believe some testing is being done in the PC environment, and I hope that we are considering the requirements of that environment in the protocol design. > Some comments to proposed RTP changes: > -------------------------------------- > > 1. Control and data on separate ports: > At the moment we are experimenting in DOS-environment and > using the PC/TCP-software. This combination limits the number > of descriptors to 20 (including file descriptors and sockets). > If several ports (and thus sockets) should be used, the maximum > descriptor count may cause problems, especially if the application > needs to operate on several files at the same time. For this > reason, the usage of separate ports should be diminished. There are some good reasons for keeping the control and data separate. Since we want PCs and UNIX boxes to interoperate, they would need to use the same rules. It seems like the 20 might not be a problem for applications such as audio + video (2+2), but some other application with lots of separate streams would be a problem. Any chance of getting the limit of 20 increased? Because it seems like you might run into that limit even with 1 port per stream. > 2. Remove Channel ID, put multiplexing into encapsulations > Does the channel ID really add so much overhead, that it should > be removed? It is not so much that the channel ID causes a lot of overhead. Rather, it is that the ILP principle says that multiplexing at several points is bad for performance. > We would like to transmit several RTP-streams (e.g. > audio and video) over a single transport connection (to be able > to get equal transport service). This could partly help in > inter-media synchronization. To put packets from multiple streams into one transport packet required an encapsulation anyway to give the length. In 32 bits we could also hold a "port" number to take the place of the channel ID. -- Steve ------- From rem-conf-request@es.net Sun Jun 19 11:49:05 1994 Received: from RUTGERS.EDU by osi-west.es.net via ESnet SMTP service id <03470-0@osi-west.es.net>; Sun, 19 Jun 1994 08:48:22 +0000 Received: by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA14124; Sun, 19 Jun 94 11:48:20 EDT To: ru-comp-dev-ietf-rem-conf@rutgers.edu Path: rutgers!relay.nswc.navy.mil!pirey%sunoco From: pirey%sunoco@relay.nswc.navy.mil (Phil Irey) Newsgroups: ru.comp.dev.ietf.rem-conf Subject: Does NV support S-VHS? Message-Id: <9406161342.AA06233@vaxless.b35ita.sunoco> Date: 16 Jun 94 04:42:42 GMT Sender: thayes@rutgers.edu Lines: 6 Is there a way to select the Super VHS input on a VideoPix or SunVideo board from NV? thanks, phil From rem-conf-request@es.net Sun Jun 19 16:48:12 1994 Received: from philabs.philips.com by osi-west.es.net via ESnet SMTP service id <03946-0@osi-west.es.net>; Sun, 19 Jun 1994 13:47:45 +0000 Received: from mars.Philabs.Philips.Com by philabs.Philips.COM (smail2.5/12-15-87/4.1) id AA13424; Sun, 19 Jun 94 16:47:43 EDT Received: by mars.Philabs.Philips.Com (4.1/SMI-4.1) id AA00571; Sun, 19 Jun 94 16:47:42 EDT Date: Sun, 19 Jun 94 16:47:42 EDT From: jec@philabs.Philips.COM (Jorge E. Caviedes) Message-Id: <9406192047.AA00571@mars.Philabs.Philips.Com> To: rem-conf@es.net Subject: MBONE in Holland Cc: jec@mars Hi there, I would like to contact anybody who is in Eindhoven or environs and has mbone connection and able to videoconference. thanks, Jorge E. Caviedes Senior Member Research Staff Image Processing Department Philips Laboratories Briarcliff Manor, NY From rem-conf-request@es.net Mon Jun 20 02:06:26 1994 Received: from aeffle.Stanford.EDU by osi-west.es.net via ESnet SMTP service id <05102-0@osi-west.es.net>; Sun, 19 Jun 1994 23:05:51 +0000 Received: (from mosedale@localhost) by aeffle.Stanford.EDU (8.6.8.1/8.6.6) id XAA01534; Sun, 19 Jun 1994 23:07:27 -0700 From: Dan Mosedale Message-Id: <199406200607.XAA01534@aeffle.Stanford.EDU> Subject: Prelim. Announce- ISMB 94 conference multicast To: rem-conf@es.net Date: Sun, 19 Jun 1994 23:07:27 -0700 (PDT) Cc: mbone@isi.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1712 ISMB-94 The Second International Conference on Intelligent Systems for Molecular Biology Stanford University MBONE broadcast: August 15-17, 1994 We plan to broadcast the scientific sessions (ie mostly refereed paper presentations) of ISMB over the MBONE. The hope is to send out two video channels (each at default bandwidth of 128 Kbps) to the entire MBONE world, as well as a whiteboard session and a vat audio session. The multicast will last from the morning of Monday the 15th of August through the evening of Wednesday the 17th. Please contact me (mosedale@genome.Stanford.EDU) as soon as you can if you know of any possible MBONE usage conflicts during that time. A short description of the conference is attached; more complete info can be found at file://camis.stanford.edu/pub/altman/www/ismb.html Thanks, Dan Sponsored by: Department of Energy National Center for Human Genome Research (NIH) National Library of Medicine (NIH) The Second International Conference on Intelligent Systems for Molecular Biology (ISMB) will take place at Stanford University, Palo Alto, California on August 14-17, 1994. The ISMB conference is intended to bring together scientists who are applying the technologies of advanced data modeling, machine learning, artificial intelligence, robotics, parallel computing, and other computational methods to problems in molecular biology. The scope extends to any computational or robotic system supporting a biological task that is cognitively challenging, involves a synthesis of information from multiple sources at multiple levels, or in some other way exhibits the abstraction and emergent properties of an "intelligent system." From rem-conf-request@es.net Mon Jun 20 03:43:59 1994 Received: from survis.surfnet.nl by osi-west.es.net via ESnet SMTP service id <05635-0@osi-west.es.net>; Mon, 20 Jun 1994 00:43:31 +0000 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <23466-0@survis.surfnet.nl>; Mon, 20 Jun 1994 09:42:33 +0200 To: jec@philabs.philips.com (Jorge E. Caviedes) Cc: rem-conf@es.net Subject: Re: MBONE in Holland In-reply-to: Your message of Sun, 19 Jun 1994 16:47:42 -0400. From: Erik-Jan Bos X-Mailer: MH X-Organization: SURFnet bv, Utrecht, The Netherlands X-Phone-Number: +31 30 310290 X-Fax-Number: +31 30 340903 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23463.772098145.1@SURFnet.nl> Date: Mon, 20 Jun 1994 09:42:25 +0200 Sender: Erik-Jan.Bos@SURFnet.nl Message-ID: <"survis.sur.470:20.05.94.07.42.36"@surfnet.nl> Jorge, > I would like to contact anybody who is in Eindhoven or environs and > has mbone connection and able to videoconference. To my knowledge, as IP service provider in The Netherlands, there is no Mbone tunnel to Eindhoven. The only "megabit site" in Eindhoven is Eindhoven University of Technology and we do not have a tunnel to them (yet). Hope this helps. __ Erik-Jan. From rem-conf-request@es.net Mon Jun 20 05:49:54 1994 Received: from oznet.ozemail.com.au by osi-west.es.net via ESnet SMTP service id <06419-0@osi-west.es.net>; Mon, 20 Jun 1994 02:49:16 +0000 Received: from ozemail.com.au (cerebus.ozemail.com.au [203.2.192.66]) by oznet.ozemail.com.au (8.6.5/8.6.5) with SMTP id TAA11768 for ; Mon, 20 Jun 1994 19:47:10 +1000 Original-Received: by ozemail.com.au from NetWare MHS, SMF-70 via XGATE 2.12 MHS to SMTP Gateway (XSMTP Module) PP-warning: Illegal Received field on preceding line Message-ID: <1994JUN20.3219@ozemail.com.au> Date: Mon, 20 Jun 94 19:54:22 +1000 From: STEVEN BYRNE To: rem-conf@es.net Subject: UNSUBSCRIBE X-mailer: XGATE 2.12 MHS/SMTP Gateway UNSUBSCRIBE From rem-conf-request@es.net Mon Jun 20 10:48:52 1994 Received: from cyceron.fr by osi-west.es.net via ESnet SMTP service id <07362-0@osi-west.es.net>; Mon, 20 Jun 1994 07:48:17 +0000 Received: from indigo1.cyceron.fr by aries.cyceron.fr via SMTP (920330.SGI/921123.CYCERON) for rem-conf@es.net id AA28557; Mon, 20 Jun 94 16:49:50 +0100 Received: by indigo1.cyceron.fr (920330.SGI/920502.SGI) for @aries.cyceron.fr:rem-conf@es.net id AA14907; Mon, 20 Jun 94 16:49:49 +0100 Date: Mon, 20 Jun 94 16:49:49 +0100 From: travere@indigo1.cyceron.fr (Jael.Travere@Cyceron.Fr) Message-Id: <9406201549.AA14907@indigo1.cyceron.fr> To: rem-conf@es.net Subject: UNSUBSCRIBE UNSUBSCRIBE Jael.Travere@Cyceron.Fr ___________________________________________________________ J.M Travere, Ph. D Cyceron PET Research Center CEA/DSV/DRIPP Bd Becquerel - BP 5229 Comp. Sc. Manager 14074 - Caen - CEDEX France Std : (+33) 31 47 02 00 Tel : (+33) 31 47 02 14 Fax : (+33) 31 47 02 22 ___________________________________________________________ From rem-conf-request@es.net Mon Jun 20 11:26:43 1994 Received: from sun2.mhs-relay.ac.uk by osi-west.es.net via ESnet SMTP service id <07480-0@osi-west.es.net>; Mon, 20 Jun 1994 08:26:08 +0000 Via: uk.ac.de-montfort; Mon, 20 Jun 1994 16:25:49 +0100 Received: from maple.cms.dmu.ac.uk by helios.dmu.ac.uk with SMTP; Mon, 20 Jun 94 16:25:38 BST Received: by maple.cms.dmu.ac.uk (1.37.109.9/2.1.1) id AA2892546343; Mon, 20 Jun 1994 16:26:00 +0100 From: Steve Thomas Date: Mon, 20 Jun 1994 16:26:00 +0100 Message-Id: <199406201526.AA2892546343@maple.cms.dmu.ac.uk> Subject: mbone and hp's Apparently-To: rem-conf@net.es Hi, here at De Montfort University (UK) we're just beginning to discover the mbone world. Could someone please advise as to what our next steps should be. We're using our HP 715 labs, with hp-ux 9.01, and so far have the hp binaries of wb, sd, vat and ivs, and tested vat point-to-point. We've got the hp-ux multicast binary, though its not been booted yet. Any help, especially from hp users would be greatly appreciated... Steve Thomas De Montfort Uni Apologies if this message is misplaced. From rem-conf-request@es.net Mon Jun 20 14:33:02 1994 Received: from pinyon.libre.com by osi-west.es.net via ESnet SMTP service id <08379-0@osi-west.es.net>; Mon, 20 Jun 1994 11:32:21 +0000 Received: from localhost (markeson@localhost) by pinyon.libre.com (8.6.4/8.6.4) id LAA06897; Mon, 20 Jun 1994 11:24:41 -0700 Date: Mon, 20 Jun 1994 11:24:16 -0700 (MST) From: Mark Markeson To: rem-conf@es.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII UNSUBSCRIBE markeson@libre.com From rem-conf-request@es.net Mon Jun 20 18:25:47 1994 Received: from godzilla.cgl.citri.edu.au by osi-west.es.net via ESnet SMTP service id <09722-0@osi-west.es.net>; Mon, 20 Jun 1994 15:25:19 +0000 Received: by godzilla.cgl.citri.edu.au id AA00644 (5.65c/IDA-1.4.4 for graphics); Mon, 20 Jun 1994 19:55:35 +1000 Date: Mon, 20 Jun 1994 19:55:35 +1000 From: Kerry Gigante Message-Id: <199406200955.AA00644@godzilla.cgl.citri.edu.au> To: graphics@cgl.citri.edu.au Subject: Computer Graphics International '94; Melbourne, Australia Next Week Computer Graphics Internation '94, the twelfth in the CGI series, will be held next week (June 27 - July 1 1994) at RMIT in Melb, Australia. The three components of the conference are 1) Pre-conference seminars 2) technical program and 3) computer animation festival The pre-conference seminars cover: Scientific Visualisation, Volume Visualisation and Medical Imaging Image Processing and Digital Imaging Fractals 3D and Spatial Thinking Animation, Virtual Actors and Artificial Life Digital Multimedia Authoring for CDROM Curves and Surfaces using NURBS (Non-Uniform Rational B-Splines) The conference technical program features presentations from some of the world's leading experts on Computer Graphics. The invited speakers are Dr Turner Whitted (Keynote), Dr Geoff Wyvill, and Dr David Kirk. The computer animation festival will be showing most evenings during the conference week and is open to the public. For further enquiries, contact cgi94@godzilla.cgl.citri.edu.au From rem-conf-request@es.net Mon Jun 20 22:14:00 1994 Received: from SOLAR.RTD.UTK.EDU by osi-west.es.net via ESnet SMTP service id <10386-0@osi-west.es.net>; Mon, 20 Jun 1994 19:13:23 +0000 Received: from [128.169.8.25] (SHUTTLE.RMT.UTK.EDU) by solar.rtd.utk.edu; Mon, 20 Jun 94 22:12:34 EDT Full-Name: Greg Cole Sender: gcole@solar.rtd.utk.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Jun 1994 22:21:29 -0500 To: rem-conf@es.net From: gcole@solar.rtd.utk.edu (Greg Cole) Subject: Global Lecture Hall (GLH) 94 MBone preliminary announcement Global Lecture Hall 94 plans to broadcast on MBone Thursday, July 7 from Knoxville, Tennessee from 9:00 am - 12:00 pm (Eastern Daylight Time/U.S.A). We hope to send out 2 channels (at default video bandwidth of 128 Kbps) with worldwide scope. Please comment if there are any other MBone events planned for this period. An archive of material describing the Global Lecture Hall event will be available at: ftp://solar.rtd.utk.edu/pub/glh/ Please respond directly to Greg Cole (gcole@solar.rtd.utk.edu) if you have any questions/suggestions about the mBONE broadcast. ----------------------------------------------------------------------------- "Global Lecture Hall" (GLH) (TM) (multipoint-to-multipoint multimedia interactive videoconference) for "COMPARE AND EVALUATE AVAILABLE TECHNOLOGIES: LEARNING THROUGH USING" at the occasion of The First International Conference on Distance Education in Russia "DISTANCE LEARNING AND NEW TECHNOLOGIES IN EDUCATION" Convention Center, Russian Academy of Science Moscow, Russia July 5-8, 1994 Date: Thursday, July 7, 1994 ~~~~~ Time: 9:00 to 12:00 (Eastern Daylight Time/U.S.A.) ~~~~~ Range: (a) Via satellites: North, Central and South America; ~~~~~~ Western, Central & Eastern Europe; Scandinavia; Baltic; Ukraine, Western Russia, Mediterranean, etc. (Some depend on the satellites we are now confirming.) (b) Via Internet: Around the world with Internet nodes. PART I: GREETINGS: ~~~~~~~~~~~~~~~~~~~~~~ * Dr. Takeshi Utsumi, President of Global University/USA * Mr. Alexander N. Tihonov, President of The Association for International Education (from Moscow) * Dr. Frederico Mayor, Director General of UNESCO (Video) * President Joseph E. Johnson, The University of Tennessee (Video) * Chancellor William T. Snyder, The University of Tennessee * Dr. Glen Hall, Dean of the College of Agriculture, The University of Tennessee (Video) * Professor David A. Johnson, Former President of Fulbright Association, The University of Tennessee * Dr. Michael G. Moore, Editor of The American Journal of Distance Education (from Moscow) * Dr. Peter T. Knight, Economic Development Institute, The World Bank PART II: DEMONSTRATIONS OF DESKTOP VIDEOCONFERENCINGS: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. "Friends and Partners" World Wide Web (WWW) Server: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ By Mr. Greg Cole, The University of Tennessee and Ms. Natasha Bulashova, Institute of Biochemistry and Physiology of Microorganisms, Russian Academy of Sciences, Pushchino, Russia -- mixed media (text, graphics, image, audio, and video) information exchange via Internet, as integrating information from all of the best Internet-based tools and utili- ties -- Listservers, Gophers, WAIS databases, FTP archives, etc. -- a forerunner of "Just-In-Time," individualized, asynchronous education. 2. CU-SeeMe via Internet: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ By Mr. Richard Cogger of Cornell University, Apple/Moscow and others, -- a black and white video (10 to 15 frame per second [fps]) with Macintosh and IBM compatible machines -- may also include audio conferencing via Internet. 3. MBONE via Internet: ~~~~~~~~~~~~~~~~~~~~~~~~~ By Messrs Mike McCann and Donald Paul Brutzman of the U.S. Naval Postgraduate School and others, -- text, graphics, image, whiteboard, audio, and video (1 to 3 fps) via 200 Kbps bandwidth -- with scientific visualizations of a global circulation model for ocean currents. 4. ShowMe via Internet: ~~~~~~~~~~~~~~~~~~~~~~~~~~ By Messrs Ren Moore and Rob Hall of Sun Microsystems, Inc. in California and Moscow (and possible participation from Sidney, Australia, too) -- text, graphics, image, whiteboard, audio, and video (10 to 15 fps). 5. ShareView via ordinary telephone and INMARSAT satellite: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ By Mr. Jim Miller of SYNECTICS -- text, graphics, image, whiteboard, audio, and video (10 to 15 fps) via 9.6 Kbps bandwidth. ShareView with a Magnavox portable dish antenna at Moscow conference site will be connected with a ShareView at the U. of TN (or Governors State University and/or Nebraska Educational TV which will be relayed to the U. of TN via satellite), and next with the World Bank which will be relayed to the U. of TN via PictureTel. 6. "Multimedia of America (MMOA)" (TM) (tentative): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ShareView at Moscow conference site will be directly connected with a ShareView at the U. of TN with the use of a portable dish antenna of Mobile Telesystems Inc. (MTI) -- via two hops of INMARSAT satellite audio channel. Interconnection of two ShareView units via audio subchannels of a satellite will also be demonstrated by Dr. Mel Muchnik of Governors State University and Mr. Timothy Cook of Nebraska Educational TV. Each of them will uplink analog signals which will be downlinked at the U. of TN to produce two split screens side-by-side, so that how to teach Japanese Kanji brush stroke sequences to students at GSU can be shown on whiteboard of ShareView unit. These demonstrations of a one-to-many receive-only ShareView system via inexpensive narrow-band channel of satellite, are intended for students in rural and remote areas where there is no Internet node, as explained in the Call for Participation in Project MMOA memo [see GN/GE/IV/1 for GLOSAS' Project Multi-Media of America (MMOA)(TM) **]. Video of instructor, handwriting in color on an electronic whiteboard, image/graphic with annotation, dynamic graphic presentation by real-time execution of an application program/simulation model, etc., can be seen in windows on computer screen at students' sites. Yet these experiences can include high levels of interaction and feedback (via email, fax, etc.) amongst students and instructors. ------ OBJECTIVES: ~~~~~~~~~~~ * To demonstrate "Global Lecture Hall" (GLH) (TM) videoconference technology for the Moscow conference attendees, so that they can compare and evaluate various delivery technologies for their global electronic distance education exchange across Atlantic Ocean, * To hold "get-acquainted face-to-face" meeting via satellite between American and Bulgarian schools, for the University of Tennessee's newly launched distance education program on "Management for Sustainable Natural Resource Development and Environmental Protection," * To demonstrate cooperation of international and domestic, governmental, industrial and academic organizations for a global scale project. PARTICIPATION: ~~~~~~~~~~~~~~ The computer screen will be uplinked for worldwide broadcast. If you have a satellite downlink facility and our satellite foot-prints cover your area, you can receive our satellite signal. You can also participate with your personal computer and/or workstation which are directly connected to TCP/IP oriented Internet without use of satellite nor dish antenna. DELIVERY: ~~~~~~~~~ 1. INTELSAT, INMARSAT, several U.S. domestic satellites, digital video equipment, etc. 2. Internet for CU-SeeMe (first priority to overseas users, total 25), and MBONE users around the world. (CU-SeeMe participants need to access its specified reflector, and call into an audio bridge at our videoconference center at the University of Tennessee.) Greg Cole Research Services The University of Tennessee Phone: (615) 974-2908 211 Hoskins Library FAX: (615) 974-6508 Knoxville, TN 37996 Email: gcole@solar.rtd.utk.edu From rem-conf-request@es.net Wed Jun 22 06:17:09 1994 Received: from rx7.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <02126-0@osi-west.es.net>; Wed, 22 Jun 1994 03:16:50 +0000 Received: by rx7.ee.lbl.gov for rem-conf@es.net (5.65/1.44r) id AA00820; Wed, 22 Jun 94 03:18:23 -0700 Message-Id: <9406221018.AA00820@rx7.ee.lbl.gov> To: rem-conf@es.net Subject: new vat (v3.4) available for anonymous ftp Date: Wed, 22 Jun 94 03:18:21 PDT From: Van Jacobson There's a new version of vat available for anonymous ftp from ftp.ee.lbl.gov in conferencing/vat/*-vat-3.4.tar.Z. This release should fix the long-standing problem of vat aborting on some Solaris-2 machines (thanks to Atanu Ghosh of University College London who figured out the bug that we've spent the past year searching for). It should also fix the problem where vat would occasionally "lock up" using 100% of the cpu on HPUX systems. This version also tries to implement the MBone ttl/bandwidth guidelines. E.g., if you start vat at ttl 220, the 80Kb/s pcm encodings are not available. If vat's requested start-up format uses too much bandwidth for the ttl, the format is silently changed to one that is compatible with the ttl. (this is so that new users don't have to know the relationship between encoding, bandwidth & ttl when creating their sd sessions and for backwards compatibility.) Appended is the complete list of changes. - Van Jacobson & Steve McCanne -------------- v3.4 Tue Jun 21 23:45:37 PDT 1994 - Fixed longstanding bug that caused core dumps under Solaris-2 if you don't define Vat.sessionName and your shell doesn't set the USER environment variable (e.g., Solaris /bin/sh and /bin/ksh). Bug report and diagnosis from Atanu Ghosh . - Fixed (I hope) problem where hp vat would occasionally lock up. My guess is that scheduling delays occasionally cause us to get behind & the kernel audio input buffer overflows so the driver goes into 'pause' (a really stupid design decision on hp's part) and we have to manually unpause it or we get continuous EIO errors. - Implement MBone ttl/bandwidth guidelines in vat encoding choices: If ttl>160, pcm format is not allowed. If ttl>192, pcm2 & pcm4 format not allowed. If ttl>200, only gsm & lpc allowed. (We're getting really tired of people running 80Kb/s pcm at ttl 255.) - Fixed initial value of idleDropTime so that vat will drop the audio device when it's not using it. (Value was 0, changed to 20 seconds - I thought I'd made this change in v3.3 but apparently botched it.) - Save & restore monitor gain & record/play balance setting in sun audio driver so that these values are local to a vat session. (suggested by Toerless Eckert) - Added [net localaddr] & [net localport] tcl commands to get local ip address & port. - Added Vat.afSoftOuputGain and Vat.afSoftInputGain resources which control the software gain settings (in dB) for AudioFile when using hardware gain control. (Vat queries the server to see if it can support hardware gain control. If so, the mike slider controls the hardware gain factor and the above attributes control an additional software gain factor, both of which are done inside the AudioFile server. If the server does not support hardware gain, then the above resources are ignored and the slider controls the software gain level directly.) These resources were added because the default behavior of the Aj300 server results in mike levels that are too low even with the hardware gain maxed out. We've found that afSoftInputGain set to 10 (dB) provides a good level (with our mikes). There seems to be a bug in the Aj300 server which causes substantial distortion when afSoftOuputGain is set to anything other than 0 (the default). At least afSoftInputGain works. - Change tk color allocation code so that any request for a gray gets mapped into the closest one of the 32 grays that nv/ivs/vic use so that vat won't take up any extra cells in the colormap (colormap problems noted & alternate fix suggested by Mark Handley at UCL). - Removed hack that worked around 'sticky' socket error indication in OSF/1.3 since OSF/2.0 seems to have fixed the kernel. From rem-conf-request@es.net Wed Jun 22 06:58:27 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <02258-0@osi-west.es.net>; Wed, 22 Jun 1994 03:58:06 +0000 Received: from danger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 22 Jun 1994 11:57:39 +0100 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: Stephen Casner cc: mosedale@genome.stanford.edu, rem-conf@es.net Subject: Re: Collected rem-conf wisdom & where 2 announce In-reply-to: Your message of "Thu, 16 Jun 94 17:55:17 PDT." <771814517.0.CASNER@XFR.ISI.EDU> Date: Wed, 22 Jun 94 11:57:34 +0100 Sender: M.Handley@cs.ucl.ac.uk >> - what are the various problems associated with accepting audio >> questions from the net and broadcasting them into the audio >> system of the conference room? > >If you use the "Net mutes mike" option on whatever output port you >connect to the room audio system, it works reasonably well. The >biggest problem is making sure you have a clean audio signal at the >right level going both ways. If you have access to the room ahead of >time and can test all of this, you should be able to make it work >fine. I agree that for questions, net mutes mike is fine, but we've had too many bad experiences with listeners transmitting spurious garbage and cutting out the talk transmission. I always use "mike nutes net", during the talk itself, and then either manually mute/unmute during questions, or then switch to net mutes mike. Both require a fair bit of dexterity at the right moment, and I've been meaning to modify vat's tcl to give easier access to this for seminar transmissions. >> - given that many folks seem to be announcing their conferences on >> the mbone list rather than rem-conf lately, is it now acceptable >> to post announcements both places so that folks who don't know >> about rem-conf will see them? > >I still suggest that rem-conf is the right place, assuming that most >people on mbone are also on rem-conf. However, since announcements >tend to be isolated messages, rather than the start of a discourse, >there's less harm done when an anouncement goes to both. I agree rem-conf is the right place. >> - is there a good way to avoid the phenomenon where the camera >> focused on the overhead screen sees the screen being much >> brighter in the center (because of the overhead projector bulb)? >Get a better projector? Or better still, get the slides in postscript and use wb. If you approach speakers in advance, very many are extremely helpful. >> - why do most conferences have two separate nv sessions for slides >> and speaker video -- why not just have a single nv window with >> two video sources? > >Good question. One possible reason is that in areas where multicast >pruning is in use, if only one channel is selected in some part of the >tree then the traffic for the other channel won't be delivered in that >part of the tree. sd only lets you set one ttl for the entire session. The slides video is much more important and unusally lower bandwidth than the speaker video, so it often makes sense to send the slides at the same ttl as the audio, and the speaker video at a lower ttl. Thus even without pruning, you can tailor the session to be receivable at various sites. However, this reason is possibly less so than it was, as it used to be the case that people tailored their tunnels to the multicast they wanted to listen to. Now there are many multicast and the Mbone is much more static than it was, so people don't do this anymore (unless you're a leaf). MOst "international" (should that read intercontinental? international in Europe should be 63) sessions now go out at ttl=127. I'm unclear how many extra people you'd include by going to 191, or more, and I'm also unclear how much bandwidth it is reasonable to push out at these ttls before you'll flood the links set up with a ttl of 128 or more. Mark From rem-conf-request@es.net Wed Jun 22 07:59:22 1994 Received: from maze.ruca.ua.ac.be by osi-west.es.net via ESnet SMTP service id <02467-0@osi-west.es.net>; Wed, 22 Jun 1994 04:59:02 +0000 Received: by maze.ruca.ua.ac.be (1.37.109.4/16.2) id AA25127; Wed, 22 Jun 94 13:58:01 +0200 From: Dirk Meersman Subject: remote confrerence announcements To: rem-conf@es.net Date: Wed, 22 Jun 94 13:58:00 METDST Mailer: Elm [revision: 70.85] I would like to be informed about the planned remote confrerences. Can you help me ? Thanks, Dirk -- _/ _/ _/_/_/ OFFICE : Meersman Dirk _/_/ _/_/ _/ _/ VISIONLAB, Dep. of Physics _/ _/ _/ _/ _/ RUCA, University of Antwerp _/ _/ _/ _/ Groenenborgerlaan 171 _/ _/eersman _/_/_/irk BELGIUM VOICE : +32 3 218 05 18 FAX : +32 3 218 02 57 E-Mail: meersman@ruca.ua.ac.be From rem-conf-request@es.net Wed Jun 22 13:34:11 1994 Received: from bimini.Stanford.EDU by osi-west.es.net via ESnet SMTP service id <03970-0@osi-west.es.net>; Wed, 22 Jun 1994 10:33:52 +0000 Received: (from petrie@localhost) by bimini.Stanford.EDU (8.6.8/8.6.6) id KAA17865; Wed, 22 Jun 1994 10:33:51 -0700 Sender: Charles Petrie Date: Wed, 22 Jun 1994 10:33:50 PDT From: petrie@sunrise.stanford.edu Reply-To: petrie@sunrise.stanford.edu To: rem-conf@es.net Cc: vinay@eit.com, gak@eit.com Subject: PostScript Limitation Message-ID: Does anyone have a way around the 30K limitation for a PostScript file size in Shared Whiteboard on Mbone please? Charles Petrie ----------------------------------------- Stanford Center for Design Research WWW URL http://cdr.stanford.edu/ From rem-conf-request@es.net Wed Jun 22 14:17:51 1994 Received: from merit.edu by osi-west.es.net via ESnet SMTP service id <04153-0@osi-west.es.net>; Wed, 22 Jun 1994 11:17:33 +0000 Received: from localhost (ljb@localhost) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA22844; Wed, 22 Jun 1994 14:17:30 -0400 Message-Id: <199406221817.OAA22844@merit.edu> To: Van Jacobson , mccanne@ee.lbl.gov cc: rem-conf@es.net Subject: Re: new vat (v3.4) available for anonymous ftp In-reply-to: Your message of "Wed, 22 Jun 1994 03:18:21 PDT." <9406221018.AA00820@rx7.ee.lbl.gov> Date: Wed, 22 Jun 1994 14:17:29 -0400 From: "Larry J. Blunk" > There's a new version of vat available for anonymous ftp > from ftp.ee.lbl.gov in conferencing/vat/*-vat-3.4.tar.Z. > > This release should fix the long-standing problem of vat > aborting on some Solaris-2 machines (thanks to Atanu Ghosh > of University College London who figured out the bug that > we've spent the past year searching for). > > It should also fix the problem where vat would occasionally > "lock up" using 100% of the cpu on HPUX systems. > > This version also tries to implement the MBone ttl/bandwidth > guidelines. E.g., if you start vat at ttl 220, the 80Kb/s pcm > encodings are not available. If vat's requested start-up format > uses too much bandwidth for the ttl, the format is silently > changed to one that is compatible with the ttl. (this is so > that new users don't have to know the relationship between > encoding, bandwidth & ttl when creating their sd sessions and for > backwards compatibility.) > > Appended is the complete list of changes. > > - Van Jacobson & Steve McCanne > Van, I didn't see anything about fixing the problem with the audiocs driver on the Sparc 5. Would you happen to have a Sparc 5 around to test vat with? The problem people are seeing is that the audio device hangs anytime Vat writes any audio output. -Thanks, Larry J. Blunk From rem-conf-request@es.net Wed Jun 22 16:40:59 1994 Received: from rx7.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <05013-0@osi-west.es.net>; Wed, 22 Jun 1994 13:40:37 +0000 Received: by rx7.ee.lbl.gov for rem-conf@es.net (5.65/1.44r) id AA01868; Wed, 22 Jun 94 13:42:06 -0700 Message-Id: <9406222042.AA01868@rx7.ee.lbl.gov> To: "Larry J. Blunk" Cc: rem-conf@es.net Subject: Re: new vat (v3.4) available for anonymous ftp In-Reply-To: Your message of Wed, 22 Jun 94 14:17:29 EDT. Date: Wed, 22 Jun 94 13:42:05 PDT From: Van Jacobson Larry, As much as we would like to, we can't fix Sun kernel bugs in vat. The Sparcstation-5 kernel's audio driver is broken. Sun has a patch CD release called Solaris 2.3 ED III that fixes (or at least improves) the situation for those unfortunates running Solaris. So far as I know, there is no fix available for SunOS 4.1.3U2. Perhaps if enough people ask for it, Sun might put fixed .o's of the driver on an ftp site somewhere. - Van From rem-conf-request@es.net Wed Jun 22 17:41:22 1994 Received: from timbuk.cray.com by osi-west.es.net via ESnet SMTP service id <05286-0@osi-west.es.net>; Wed, 22 Jun 1994 14:41:05 +0000 Received: from frenzy.cray.com (frenzy-eth.cray.com) by cray.com (Bob mailer 1.2) id AA26144; Wed, 22 Jun 94 16:41:00 CDT Received: by frenzy.cray.com id AA21183; 4.1/CRI-5.6; Wed, 22 Jun 94 16:43:18 CDT Date: Wed, 22 Jun 94 16:43:18 CDT From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9406222143.AA21183@frenzy.cray.com> To: ljb@merit.edu, mccanne@ee.lbl.gov, van@ee.lbl.gov Subject: Re: new vat (v3.4) available for anonymous ftp Cc: rem-conf@es.net Larry, The problem isn't with vat, it is with /kernel/drv/audiocs. We have a new /kernel/drv/audiocs from Bob Gilligan at Sun that allows vat to work, but doesn't solve all the problems. What we were given to test is probably either the Solaris 2.4 or the Solaris 2.3 ED III version of /kernel/drv/audiocs, I'm not sure which. Assuming that it worked, Bob was planning on making it available to the community, but I haven't seen anything yet. Perhaps they are still trying to track down all the bugs before making a fix available. -David Borman, dab@cray.com > Van, > I didn't see anything about fixing the problem with the audiocs > driver on the Sparc 5. Would you happen to have a Sparc 5 around > to test vat with? The problem people are seeing is that the audio > device hangs anytime Vat writes any audio output. > > -Thanks, > Larry J. Blunk From rem-conf-request@es.net Wed Jun 22 19:53:31 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <05774-0@osi-west.es.net>; Wed, 22 Jun 1994 16:45:42 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14524(2)>; Wed, 22 Jun 1994 16:45:27 PDT Received: from localhost by ecco.parc.xerox.com with SMTP id <16150>; Wed, 22 Jun 1994 16:45:14 -0700 To: Van Jacobson cc: "Larry J. Blunk" , rem-conf@es.net Subject: Re: new vat (v3.4) available for anonymous ftp In-reply-to: Your message of "Wed, 22 Jun 94 13:42:05 PDT." <9406222042.AA01868@rx7.ee.lbl.gov> X-Mailer: exmh version 1.4 ?? 6/18/94 Date: Wed, 22 Jun 1994 16:45:13 PDT Sender: Ron Frederick From: Ron Frederick Message-Id: <94Jun22.164514pdt.16150@ecco.parc.xerox.com> In message <9406222042.AA01868@rx7.ee.lbl.gov> you write: > As much as we would like to, we can't fix Sun kernel bugs in > vat. The Sparcstation-5 kernel's audio driver is broken. Sun > has a patch CD release called Solaris 2.3 ED III that fixes (or > at least improves) the situation for those unfortunates running > Solaris. So far as I know, there is no fix available for SunOS > 4.1.3U2. Perhaps if enough people ask for it, Sun might put > fixed .o's of the driver on an ftp site somewhere. > On the Solaris 1.1.1 Rev B CD, there is a "patch_ms2" file which you need to make the SPARC-5 audio hardware work correctly. Is there a problem with vat even after installing this patch? -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Wed Jun 22 20:13:28 1994 Received: from matmos.hpl.hp.com by osi-west.es.net via ESnet SMTP service id <06061-0@osi-west.es.net>; Wed, 22 Jun 1994 17:13:09 +0000 Received: from dirtdive.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.4/HPL42.42) id AA26206; Wed, 22 Jun 94 17:13:06 -0700 Received: by dirtdive.hpl.hp.com (1.37.109.8/HPL42.42) id AA19545; Wed, 22 Jun 1994 17:13:06 -0700 Date: Wed, 22 Jun 1994 17:13:06 -0700 From: Mark Laubach Message-Id: <9406230013.AA19545@dirtdive.hpl.hp.com> To: rem-conf@es.net Subject: July 13 and 14th: First Community Networking Workshop MBONE BROADCAST --- ADVANCE NOTICE On July 13 and 14, from approximately 8:30 am to 6:00 pm, PDT, we will broadcast audio and video (nv) on the Internet MBONE the First International Workshop on Community Networking. The preliminary program is attached below. Unfortunately, we regret that we have reached the limit of the attendance that we can accommodate at the conference site. However, IEEE will make the proceedings available. For pricing and ordering instructions, send mail to cn-info@opera.hpl.hp.com after July 12. Later on we will send additional details on the broadcast. We would like to acknowledge Pacific Bell for providing the network connection and Hewlett-Packard Co. for providing the computer equipment. ============================================================================ FIRST INTERNATIONAL WORKSHOP ON COMMUNITY NETWORKING INTEGRATED MULTIMEDIA SERVICES TO THE HOME July 13-14, 1994 Westin Hotel, Millbrae, California, USA PRELIMINARY PROGRAM Session I: Architecture Elements Edward S. Szurkowski, AT&T Bell Laboratories, The AT&T Interactive Consumer Video Services Platform David Mitchell, IBM Networking Systems, Community Networking: a Lakes Approach Yee-Hsiang Chang, Hewlett-Packard Laboratories, The Concept of the Information Gateways Christian Blum, Refik Molva, and Erich Rutsche, Institut Eurocom, A Terminal-Based Approach to Multimedia Service Provision Nimish Shah, Loral Data Systems, Comparison of Architectural Elements Session II: Services and Media Creation Chuck Clanton, Aratar, Film Craft and Methodology in Interactive Multimedia Design Andrew Davidson and Charles Golvin, Philips Interactive Media of America, The Title Development Process Rick Dedrick, Intel Corporation, Interactive Electronic Advertising in the Age of the NII Kari Santos, US West Technologies, Requirements of a Home Shopping Application on a Broadband Network Al Hicks and Margaret Ann Chappell, AT&T Bell Laboratories, Consumer Interactive TV: What Comes After the Digital Set-Top Box/TV Combination Session III: Video on Demand Al Kovalick, Hewlett-Packard Video Communications Division, The Video Server as a Component in the Community Network Makoto Nishio, Makiko Yoshida and Sho-ichiro Nakai, NEC Corporation C&C Research Laboratories, VideoExpress: A Meta-Service System For Video On Demand G.H. Petit and D. Deloddere, Alcatel-Bell Mfg. Co., Bandwidth Resource Optimization in Video-On-Demand Network Architectures Tomohiro Ishihara, Jun Tanaka, Ichiro Nakajima, Masato Okuda, and Haruo Yamashita, Fujitsu Labs. Ltd., Modeling and Evaluation of Broadband Access Networks for Multimedia Services Andy Lippman, MIT Media Laboratory, The Distributed Media Bank Session IV: Performance Issues Ashok Erramilli, Edward Lipper, and Jonathan L. Wang, Bellcore, On Some Performance Considerations for Mass Market Broadband Services Matthew S. Goldman and Jeffrey B. Mendelson, Digital Equipment Corporation, Traffic Shaping and Quality of Service Issues for Delivering MPEG Transport Streams over ATM and ATM-Hybrid Interactive Multimedia Networks E. Chang and A. Zakhor, University of California, Berkeley, Variable Bit Rate MPEG Video Storage on Parallel Disk Arrays Session V: Interoperability Issues Bob Hutchinson, Hewlett Packard Interactive Television Appliances, Architectural Framework for Standardizing Multimedia H. Allen Ecker and William E. Wall, Scientific-Atlanta, Inc., Interoperability Considerations for Broadband Networks A. E. Eckberg, AT&T Bell Laboratories, Achieving Control Architecture Flexibility In Multi-Vendor Architectures Nichols, Pol, Morley, Messerschmitt, and Haskell, Philips Research, University of California at Berkeley, and Compression Labs. Inc., Multimedia Consumer Applications on a Heterogeneous Network Session VI: Distribution technology Harman, Huang, Im, Nguyen, Werner, and Wong, AT&T Bell Laboratories, Local Distribution for Interactive Multimedia TV to the Home Ray Counterman and Tom Helmes, GTE Laboratories, Shared Channel ATM Access for Hybrid Fiber/Coax Architectures Graham Campbell, Illinois Institute of Technology, Extended (X)-DQRAP: A Cable TV Protocol as a Switch Mohammad S. Shakouri, Hewlett Packard Company, Microwave Wireless Link for Broadband Multimedia S. V. Ahamed, P. L. Gruber, and J. J. Werner, AT&T Bell Laboratories, HDSL and ADSL Capacity of the Outside Loop Plant for Multimedia Services to the Home Session VII: Experiences Rick Hronicek, CalREN/Pacific Bell, Early Experiences with CalREN Projects Ton Verschuren, SURFnet bv, First steps towards multimedia data communication to the home - Experiences in the Netherlands Richard Lowenberg, Telluride Institute, Telluride InfoZone - A Program of the Telluride Institute Bruce R. Katz, The WELL, The WELL Online Community System Session VIII: Communication Software Issues Abel Weinrib, Bellcore, The Need for a Session Abstraction to Support Community Networking Applications Scott Shenker, David D. Clark, and Lixia Zhang, Xerox PARC and MIT, The Case for Network Service Model Compatibility P. Venkat Rangan and Srinivas Ramanathan, University of California, San Diego, Technologies for Distribution of Interactive Multimedia to Residential Subscribers Geng-Sheng (G.S.) Kuo, National Central University, Taiwan, A New Generalized Mechanism of Secure Internetworked Information Service Creation for Future Personal Communications Networks From rem-conf-request@es.net Wed Jun 22 20:50:22 1994 Received: from palin.cc.monash.edu.au by osi-west.es.net via ESnet SMTP service id <06225-0@osi-west.es.net>; Wed, 22 Jun 1994 17:49:37 +0000 Received: (peter@localhost) by palin.cc.monash.edu.au (8.6.8/8.6.4) id KAA03207 for rem-conf@es.net; Thu, 23 Jun 1994 10:49:28 +1000 Date: Thu, 23 Jun 1994 10:49:28 +1000 From: Peter Hawkins Message-Id: <199406230049.KAA03207@palin.cc.monash.edu.au> To: rem-conf@es.net Subject: Unsubscribe Please remove me from this list. Thankyou Peter From rem-conf-request@es.net Thu Jun 23 01:09:59 1994 Received: from merit.edu by osi-west.es.net via ESnet SMTP service id <06863-0@osi-west.es.net>; Wed, 22 Jun 1994 22:09:34 +0000 Received: from asterix.merit.edu (asterix.merit.edu [35.42.1.59]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id BAA03355; Thu, 23 Jun 1994 01:09:31 -0400 Received: from localhost (ljb@localhost) by asterix.merit.edu (8.6.5/8.6.5) with SMTP id BAA09501; Thu, 23 Jun 1994 01:09:30 -0400 Message-Id: <199406230509.BAA09501@asterix.merit.edu> X-Authentication-Warning: asterix.merit.edu: Host localhost didn't use HELO protocol X-Authentication-Warning: asterix.merit.edu: ljb owned process doing -bs To: Ron Frederick cc: Van Jacobson , rem-conf@es.net Subject: Re: new vat (v3.4) available for anonymous ftp In-reply-to: Your message of "Wed, 22 Jun 1994 16:45:13 PDT." <94Jun22.164514pdt.16150@ecco.parc.xerox.com> Date: Thu, 23 Jun 1994 01:09:29 -0400 From: "Larry J. Blunk" > In message <9406222042.AA01868@rx7.ee.lbl.gov> you write: > > As much as we would like to, we can't fix Sun kernel bugs in > > vat. The Sparcstation-5 kernel's audio driver is broken. Sun > > has a patch CD release called Solaris 2.3 ED III that fixes (or > > at least improves) the situation for those unfortunates running > > Solaris. So far as I know, there is no fix available for SunOS > > 4.1.3U2. Perhaps if enough people ask for it, Sun might put > > fixed .o's of the driver on an ftp site somewhere. > > > On the Solaris 1.1.1 Rev B CD, there is a "patch_ms2" file which you need > to make the SPARC-5 audio hardware work correctly. Is there a problem with > vat even after installing this patch? Yes, there are still problems. The patch provides support for the new audio hardware and things like soundtool seem to work okay after the patch is installed. However, the audio device hangs whenever vat writes any output to it. Audio input seems to work okay with vat (as long as you keep the output muted so the device won't hang). However, there's a recent development. I was just looking through the lastest 4.1.3U1 sun4m jumbo patch (101508-06) and noticed that the audio_4231.o module was a different size than the one in the ms2 patch. There's no mention of bug fixes for the audio in the README, but a diff on the strings -a output for the 2 modules yields the following interesting differences: 52a54 > _CS4231_reva 109a112 > _audio_4231_workaround 149c152,153 < "@(#)audio_4231.c 1.7 94/02/01 SMI --- > _audio_xmit_garbage_collect > #@(#)audio_4231.c 1.11 94/03/15 SMI I'll try out this new patch tomorrow and see if it fixes the hanging problem. -Larry Blunk Merit From rem-conf-request@es.net Thu Jun 23 03:32:38 1994 Received: from jerry.inria.fr by osi-west.es.net via ESnet SMTP service id <07509-0@osi-west.es.net>; Thu, 23 Jun 1994 00:31:51 +0000 Received: by jerry.inria.fr (5.65c8/IDA-1.2.8) id AA15832; Thu, 23 Jun 1994 09:31:18 +0200 Message-Id: <199406230731.AA15832@jerry.inria.fr> To: Ron Frederick Cc: rem-conf@es.net Subject: Re: Comments requested: RTP version 2 Date: Thu, 23 Jun 1994 09:31:16 +0200 From: Thierry Turletti Ron, Here are the main points I would like to comment on > o Control information is no longer carried as options in the RTP data > packets. Instead, control information is carried in RTCP packets on > a separate lower-layer transport association (e.g., UDP port). RTCP > packets are self-contained units that can be processed independently. > There is a hook provided to allow profile-specific extensions to the > header of data packets should a requirement arise. Fine. I already used different port numbers for control packets in ivs. > o The RTP timestamp now measures time in a clock rate defined by the > encoding rather than a fixed 65536 Hz clock. The timestamp itself has > no predictable relation to wallclock time, but the relation to an NTP > timestamp may be carried explictly in an RTCP packet. About the media dependant clock timestamp, as Christian said before, we'd rather have the previous timestamp definition. The point with media dependant clock is that the difference between real clock and media clock depends of the load of the machine. More over, we need the real clock timestamp to process the rtt max value useful for our scalable congestion control algorithm. The interarrival jitter is not significant for applications like ivs which do not send packets at regular intervals (output rate control policy, cpu limit...) Clearly, It seems that the timestamp field should also be application dependant. The talk-spurt bit for audio is not really essential but it tells us that we don't have to wait any further to get to the end of the talk-spurt. (saving of time in the playout buffer management). > o The unicast reverse path RTP control packet is eliminated because the > change in SSRC identifers and the encryption method preclude reverse > mapping in translators. Normal (multicast) RTCP is used instead. I disagree with the unicast reverse path RTP control packet removal. It is not clear that multicast reverse feedback is more convenient than simple unicast to the sources. Two policies exists: either you let the source make the decision for the participants or you let each participant process its network state and make its own decision. I'm not sure RTP should decide what policy to use. In all cases I think RTP should not decide currently what policy to use -- we really need to test & compare both schemes. BTW, I think that RTP should also consider the very large broadcast case in which the number of participants is unknown. In this case (e.g. TV broadcasted to N participants, where N is large but unknown) a very loose control scheme should be used: e.g. no control session sent by receiving-only participants. About the new SSRC Random random 32-bit Identifier How long should a shource monitor the transmission of others sources before picking its own value ? To ensure that nobody else has the same SSRC identifier, each participant needs to compare each SSRC identifier received with its own SSRC. This stuff certainly looks to me like we could live without. > o A description is included here for the RTCP FMT packet. Should this > be kept ? I'd rather use the payload type field. For example in the scalable congestion control scheme used in ivs 3.3, all video packets must include a 128-bit header and only 64 bits are useful (the 64 other bits for the FMT header ...) Regards, Thierry From rem-conf-request@es.net Thu Jun 23 08:57:59 1994 Received: from gw1.att.com by osi-west.es.net via ESnet SMTP service id <08630-0@osi-west.es.net>; Thu, 23 Jun 1994 05:57:35 +0000 Received: from mtgzfs3.mt.att.com (mtgzfs3-bgate.mt.att.com) by ig1.att.att.com id AA07603; Thu, 23 Jun 94 08:57:03 EDT Received: from mtgz828.att.com (mtgz828.mt.att.com) by mtgzfs3.mt.att.com (4.1/EMS-1.0.3 main.cf 1.37 10/5/93 (SMI-4.1/SVR4)) id AA16308; Thu, 23 Jun 94 08:55:38 EDT From: "c.t.martin" Message-Id: <9406230855.ZM1019@mtgzfs3.mt.att.com> Date: Thu, 23 Jun 1994 08:55:26 -0400 X-Mailer: Z-Mail (3.0.1 04apr94) To: rem-conf@es.net Subject: Audio only ivs? Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 I'm a new ivs user and I'm looking for some advice. Can ivs be used without a video card in an audio only mode? I'll eventually be using video but the video cards are on back order. In the mean time, I wanted to get familiar with ivs using audio only. I tried this configuration and was able to get ivs display windows up and I seemed to make a connection between endpoints but no audio was being passed from my microphone to the far end speakers. Does this problem sound familiar to anyone? I'm running on a Sparc SLC with SunOS 4.1.1. Thanks for any help you can provide. - Tim Martin AT&T Bell Labs ctm@mtgzfs3.mt.att.com From rem-conf-request@es.net Thu Jun 23 09:42:29 1994 Received: from jerry.inria.fr by osi-west.es.net via ESnet SMTP service id <08731-0@osi-west.es.net>; Thu, 23 Jun 1994 06:42:05 +0000 Received: by jerry.inria.fr (5.65c8/IDA-1.2.8) id AA16758; Thu, 23 Jun 1994 15:41:30 +0200 Message-Id: <199406231341.AA16758@jerry.inria.fr> To: "c.t.martin" Cc: rem-conf@es.net Subject: Re: Audio only ivs? In-Reply-To: Your message of Thu, 23 Jun 1994 08:55:26 -0400. <9406230855.ZM1019@mtgzfs3.mt.att.com> Reply-To: Thierry.Turletti@sophia.inria.fr Date: Thu, 23 Jun 1994 15:41:28 +0200 From: Thierry Turletti > I'm a new ivs user and I'm looking for some advice. Can ivs be used without > a video card in an audio only mode? I'll eventually be using video but the > video cards are on back order. In the mean time, I wanted to get familiar > with ivs using audio only. I tried this configuration and was able to get > ivs display windows up and I seemed to make a connection between endpoints but > no audio was being passed from my microphone to the far end speakers. Does > this problem sound familiar to anyone? I'm running on a Sparc SLC with > SunOS 4.1.1. Thanks for any help you can provide. Hi Tim, Audio and video part are independant in ivs, so you don't need to have a video board to use the audio codec. What ivs version are you using ? In the experimental 3.3 version, the speaker name is flashing in the ivs panel (such as in vat audio conferencing tool). Do you see anything flashing at the receiving/sending ivs panels ? If the receiving site is flashing then you should check if the correct output is selected (heaphone/loudspeaker and not external). If not, you should check if your microphone is correctly plugged, if the Sun microphone battery is ok (a battery is not required if you have a Sun with the SpeakerBox). The 3.3 version of IVS includes better audio stuff than in previous versions. The official version should be available soon. Regards, Thierry From rem-conf-request@es.net Thu Jun 23 11:08:20 1994 Received: from KARIBA.BBN.COM by osi-west.es.net via ESnet SMTP service id <09001-0@osi-west.es.net>; Thu, 23 Jun 1994 08:07:56 +0000 Date: Thu, 23 Jun 94 11:07:14 EDT From: Chip Elliott To: rem-conf@es.net Subject: PC Gear for Videoconferencing Hi, Has anyone bought IBM PC clones for experiments with audio/video conferencing? I'd be most interested in hearing what equipment is needed (eg FlexCam, VideoLogic boards, etc) and its rough pricing. Thanks much, - Chip Elliott From rem-conf-request@es.net Thu Jun 23 12:17:26 1994 Received: from tigger.jvnc.net by osi-west.es.net via ESnet SMTP service id <09285-0@osi-west.es.net>; Thu, 23 Jun 1994 09:16:59 +0000 Received: by tigger.jvnc.net id AA06675 (5.65c/IDA-1.4.4 for rem-conf@es.net); Thu, 23 Jun 1994 12:16:56 -0400 From: SAI Message-Id: <199406231616.AA06675@tigger.jvnc.net> Subject: Need help/pointers to multicast image data To: rem-conf@es.net Date: Thu, 23 Jun 94 12:16:56 EDT X-Mailer: ELM [version 2.3 PL11] Hi: Could someone help me or point me in the right direction ? What I need to do is to be able to send a multimedia file (image) to several users. The users could be on my own LAN or on the net over a WAN. Assume that I have their e-mail ids (xyz@somewhere.com, another@somewhereelse.com etc). Do I need to first use hardware multicasting to have these users as part of a multicast group ? When would I use IP multicasting ? How could I arrange it so that I can have these files sent to the users as I get updates, on an automatic basis , where it will be transparent to the users as well ? (i.e no ftp, etc involved). I would appreciate any help I can get Thanks in advance Andre andre@sairam.com From rem-conf-request@es.net Thu Jun 23 13:17:20 1994 Received: from sun2.mhs-relay.ac.uk by osi-west.es.net via ESnet SMTP service id <09570-0@osi-west.es.net>; Thu, 23 Jun 1994 10:12:49 +0000 Via: uk.ac.edinburgh.festival; Thu, 23 Jun 1994 18:11:52 +0100 Received: from ucs.ed.ac.uk by festival.ed.ac.uk id aa03140; 23 Jun 94 18:08 BST Received: from scorpio.ucs.ed.ac.uk by ucs.ed.ac.uk; Thu, 23 Jun 94 18:11:49 BST Date: Thu, 23 Jun 94 18:11:48 BST Message-Id: <1846.9406231711@scorpio.ucs.ed.ac.uk> From: Graeme Wood Subject: Re: Need help/pointers to multicast image data To: SAI , rem-conf@es.net In-Reply-To: SAI's message of Thu, 23 Jun 94 12:16:56 EDT Reply-To: Graeme.Wood@edinburgh.ac.uk X-Department: Unix Systems Support, Computing Services X-Organisation: The University of Edinburgh X-Url: "http://www.ucs.ed.ac.uk/~jaw/" X-Phone: +44 (0)31 650 5003 X-Fax: +44 (0)31 650 6552 > Could someone help me or point me in the right direction ? > What I need to do is to be able to send a multimedia file (image) > to several users. The users could be on my own LAN or on the net > over a WAN. Assume that I have their e-mail ids (xyz@somewhere.com, > another@somewhereelse.com etc). Do I need to first use hardware multicasting > to have these users as part of a multicast group ? > When would I use IP multicasting ? > How could I arrange it so that I can have these files sent to the users > as I get updates, on an automatic basis , where it will be transparent > to the users as well ? (i.e no ftp, etc involved). > > I would appreciate any help I can get Well it sounds like what you want is a mailing list if you have email addresses :-) but there is a tool developed at Hawaii (called imm available from ftp://ftp.hawaii.edu/paccom/imm) which we use to disseminate image files (mostly JPEG satellite images). I can think of no reason why you could not use the same tool to distribute other kinds of file though, be they JPEG images or whatever; the client software is configurable to allow you to store an archive of the files it receives rather than display them. If you were to use this tool (or something similar) then you would need to ensure that you and all your receivers were on stations capable of receiving IP multicast. Graeme Wood From rem-conf-request@es.net Thu Jun 23 14:45:35 1994 Received: from merit.edu by osi-west.es.net via ESnet SMTP service id <10078-0@osi-west.es.net>; Thu, 23 Jun 1994 11:42:05 +0000 Received: from localhost (ljb@localhost) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA24011; Thu, 23 Jun 1994 14:41:45 -0400 Message-Id: <199406231841.OAA24011@merit.edu> To: Ron Frederick cc: Gunnar Lindberg , Jack.Jansen@cwi.nl, casner@isi.edu, deering@parc.xerox.com, mccanne@ee.lbl.gov, van@ee.lbl.gov, rem-conf@es.net Subject: Re: vat and Solaris 1.1.1 on Sparc 5's In-reply-to: Your message of "Thu, 23 Jun 1994 08:54:27 PDT." <94Jun23.085433pdt.16150@ecco.parc.xerox.com> Date: Thu, 23 Jun 1994 14:41:35 -0400 From: "Larry J. Blunk" > Yes - apparently there is some sort of bug in Sun's new SS5 audio support, > even after you install patch_ms2. There's no documented fix for it on SunOS > 4.1.3 yet. However, Larry Blunk mentioned something about a > newer audio_4231.o which he found in another jumbo patch, and he said he > would give it a try and see if it fixed things. I have added Larry to the > cc list of this message. > -- > Ron Frederick > frederick@parc.xerox.com Good News, The 101508-06 patch seems to fix the problems with the CS4231 audio device on the Sparc 5 when using vat. However, the audio_4231_bsize value seems a wee bit high: audio_4231_bsize/D _audio_4231_bsize: _audio_4231_bsize: 8180 I'm guessing folks will want to patch this down to 160 as follows: adb -k -w /vmunix /dev/mem audio_4231_bsize/W 0t160 (to patch the running kernel) audio_4231_bsize?W 0t160 (to patch kernel file on disk) -Larry Blunk Merit Network, Inc. From rem-conf-request@es.net Thu Jun 23 16:51:25 1994 Received: from merit.edu by osi-east.es.net via ESnet SMTP service id <20088-0@osi-east.es.net>; Thu, 23 Jun 1994 13:51:09 +0000 Received: from localhost (ljb@localhost) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA02966; Thu, 23 Jun 1994 16:48:15 -0400 Message-Id: <199406232048.QAA02966@merit.edu> To: ljb@merit.edu cc: Ron Frederick , Gunnar Lindberg , Jack.Jansen@cwi.nl, casner@isi.edu, deering@parc.xerox.com, mccanne@ee.lbl.gov, van@ee.lbl.gov, rem-conf@es.net Subject: Re: vat and Solaris 1.1.1 on Sparc 5's In-reply-to: Your message of "Thu, 23 Jun 1994 14:41:35 EDT." <199406231841.OAA24011@merit.edu> Date: Thu, 23 Jun 1994 16:48:06 -0400 From: "Larry J. Blunk" > Good News, > The 101508-06 patch seems to fix the problems with the CS4231 audio device > on the Sparc 5 when using vat. However, the audio_4231_bsize value seems > a wee bit high: > > audio_4231_bsize/D > _audio_4231_bsize: > _audio_4231_bsize: 8180 > > I'm guessing folks will want to patch this down to 160 as follows: > > adb -k -w /vmunix /dev/mem > audio_4231_bsize/W 0t160 (to patch the running kernel) > audio_4231_bsize?W 0t160 (to patch kernel file on disk) ARGHH. Looks like I spoke too soon. There still seems to be a few problems with the driver. First, whenever there is audio output there are frequent loud "pops" in the output. Second, after running with a continuous audio stream for awhile (with a Radio Free Vat session), the driver spits out the following messages to the console: DMA_SETUP failed in play! DMA_SETUP failed in play! DMA_SETUP failed in record! DMA_SETUP failed in record! then the machine enters a semi-hung state requiring a L1-A and a reboot. I've tried this twice (once with audio_4231_bsize changed to 160 and once without) and the same thing happened both times. Looks like this isn't quite ready for prime-time. -Larry From rem-conf-request@es.net Thu Jun 23 19:32:05 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <02053-0@osi-west.es.net>; Thu, 23 Jun 1994 16:31:42 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14559(1)>; Thu, 23 Jun 1994 16:31:16 PDT Received: from localhost by ecco.parc.xerox.com with SMTP id <16150>; Thu, 23 Jun 1994 16:31:04 -0700 To: Thierry Turletti cc: rem-conf@es.net Subject: Re: Comments requested: RTP version 2 In-reply-to: Your message of "Thu, 23 Jun 94 00:31:16 PDT." <199406230731.AA15832@jerry.inria.fr> X-Mailer: exmh version 1.4 ?? 6/18/94 Date: Thu, 23 Jun 1994 16:30:50 PDT Sender: Ron Frederick From: Ron Frederick Message-Id: <94Jun23.163104pdt.16150@ecco.parc.xerox.com> In message <199406230731.AA15832@jerry.inria.fr> you write: >> o The RTP timestamp now measures time in a clock rate defined by the >> encoding rather than a fixed 65536 Hz clock. The timestamp itself has >> no predictable relation to wallclock time, but the relation to an NTP >> timestamp may be carried explictly in an RTCP packet. > > About the media dependant clock timestamp, as Christian said before, we'd > rather have the previous timestamp definition. The point with media dependant > clock is that the difference between real clock and media clock depends of > the load of the machine. More over, we need the real clock timestamp to > process the rtt max value useful for our scalable congestion control > algorithm. The interarrival jitter is not significant for applications like > ivs which do not send packets at regular intervals (output rate control > policy, cpu limit...) Clearly, It seems that the timestamp field should also > be application dependant. > It was true in the past that the timestamp field was supposed to hold the exact time the samples were picked up by the microphone, even though it happened to be expressed in these arbitrary 65536Hz units. In order to get this time in a way which is truly independent of the load on the machine, you had to cheat and only query the time occasionally (like at the start of a talkspurt) and compute the times that went into successive packets based on the amount of audio present in the packet. All we have done here is allowed the clock frequency to be something which makes this process easier -- it can now be the same as the sampling rate, for example, to make the math simpler. It was never the case that the timestamp field was supposed to represent the time the packet was put on the wire. If you want to compute a RTT, there is a way to do that in RTPv2 using the session packets. In that case, the NTP timestamp in the sender report _is_ supposed to be the time the packet was put on the wire. In the receiver reports that come back, there is a field which holds the amount of time between when the receiver got the sender report and when they generated their reply. This gives you enough information to compute round trip time to that receiver. I'm not sure what you mean by the timestamp field being application dependent. It is already profile & payload-type dependent. However, in order for two different applications operating under the same profile to interoperate, its meaning has to be specified exactly by that profile. > The talk-spurt bit for audio is not really essential but it tells us > that we don't have to wait any further to get to the end of the talk-spurt. > (saving of time in the playout buffer management). > I'm going to abstain from this argument, on the grounds that I have not tried to implement an RTP audio application. However, let me just say that it was a point of hot debate between the authors of the draft. It is actually not something which the main RTP spec will specify, but a decision will have to be made in the audio/video profile. >> o The unicast reverse path RTP control packet is eliminated because the >> change in SSRC identifers and the encryption method preclude reverse >> mapping in translators. Normal (multicast) RTCP is used instead. > > I disagree with the unicast reverse path RTP control packet removal. It is > not clear that multicast reverse feedback is more convenient than > simple unicast to the sources. Two policies exists: either you let the source > make the decision for the participants or you let each participant process > its network state and make its own decision. > > I'm not sure RTP should decide what policy to use. In all cases I think RTP > should not decide currently what policy to use -- we really need to test & > compare both schemes. BTW, I think that RTP should also consider the > very large broadcast case in which the number of participants is unknown. > In this case (e.g. TV broadcasted to N participants, where N is large but > unknown) a very loose control scheme should be used: e.g. no control session > sent by receiving-only participants. > There's a lot of hair added to bridges and translators to deal with forwarding unicast backchannel information. It was a significant savings in the design to remove this feature. The benefit of using unicast instead of multicast is much less clear, especially given the difficulty in making unicast reporting scale in a reasonable way. As for the very large conference, it isn't clear that the "right" answer is for all receive-only participants to stop reporting. There are many ways to make a large conference scale while still getting some report information back. > About the new SSRC Random random 32-bit Identifier > How long should a shource monitor the transmission of others sources > before picking its own value ? To ensure that nobody else has the same SSRC > identifier, each participant needs to compare each SSRC identifier received > with its own SSRC. This stuff certainly looks to me like we could live > without. > One of the things not yet completed in the current draft is the wording that provides guidelines about issues like this, and perhaps sample implementations. You don't need to be 100% sure that no one else is using the identifier, though. You just need to be able to detect identifier collisions and recover from them. A compliant implementation could be written which started out and immediately chose a random identifier, as long as it did the proper thing to resolve collisions later. Listening for a while just reduces the change that this will need to happen. >> o A description is included here for the RTCP FMT packet. Should this >> be kept ? > > I'd rather use the payload type field. For example in the scalable > congestion control scheme used in ivs 3.3, all video packets must include a > 128-bit header and only 64 bits are useful (the 64 other bits for the FMT > header ...) > I think you misunderstood the intention here. The FMT option does not get sent in the data packets, and it does not replace the payload type field. It is simply used to define addition mappings of the payload type to encoding for types which are not well-known. When it is used, it is sent in control packets periodically. The question about whether to keep it was mainly whether or not we need to provide a mechanism in RTP for this. Most of the time, the well-known encodings should serve the purpose just fine. In the rare case where they don't, the negotiation of the new format could be done by out of band means (such as in the session announcement). The main problem with doing it at the RTP level is that now the receiver needs to keep a separate payload mapping for each sender, instead of one for the whole conference. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Fri Jun 24 04:16:01 1994 Received: from jerry.inria.fr by osi-west.es.net via ESnet SMTP service id <01563-0@osi-west.es.net>; Fri, 24 Jun 1994 01:15:15 +0000 Received: by jerry.inria.fr (5.65c8/IDA-1.2.8) id AA18258; Fri, 24 Jun 1994 10:14:45 +0200 Message-Id: <199406240814.AA18258@jerry.inria.fr> To: Ron Frederick Cc: rem-conf@es.net Subject: Re: Comments requested: RTP version 2 In-Reply-To: Your message of Thu, 23 Jun 1994 16:30:50 -0700. <94Jun23.163104pdt.16150@ecco.parc.xerox.com> Reply-To: Thierry.Turletti@sophia.inria.fr Date: Fri, 24 Jun 1994 10:14:42 +0200 From: Thierry Turletti > There's a lot of hair added to bridges and translators to deal with forwarding > unicast backchannel information. It was a significant savings in the design to > remove this feature. The benefit of using unicast instead of multicast is much > less clear, especially given the difficulty in making unicast reporting scale > in a reasonable way. We hope our scalable congestion control scheme resolve this issue. More experiments are still required but preliminary results are cheering. I don't want to impose this scheme, I only hope to use the new RTP to test it further. > As for the very large conference, it isn't clear that the "right" answer is for > all receive-only participants to stop reporting. There are many ways to make a > large conference scale while still getting some report information back. Hmm. I didn't mean no ``QoS'' reports from receive-only participants but useless periodic control messages such as SDES ... Sure, we need to have an estimate of the global network state. I just wanted to consider the case where the identity and the number of participants in the conference is large and unknown; I didn't see any hook in RTP. > One of the things not yet completed in the current draft is the wording that > provides guidelines about issues like this, and perhaps sample implementations. > You don't need to be 100% sure that no one else is using the identifier, > though. You just need to be able to detect identifier collisions and recover > from them. A compliant implementation could be written which started out and > immediately chose a random identifier, as long as it did the proper thing to > resolve collisions later. Listening for a while just reduces the change that > this will need to happen. You're right, maybe such guidelines and sample implementations should be useful. > I think you misunderstood the intention here. The FMT option does not get sent > in the data packets, and it does not replace the payload type field. It is > simply used to define addition mappings of the payload type to encoding for > types which are not well-known. When it is used, it is sent in control packets > periodically. Oops, I mixed up FMT and APP specific option. Is there any way to reduce the APP options overhead ? Thierry Turletti From rem-conf-request@es.net Fri Jun 24 09:56:42 1994 Received: from mitsou.inria.fr by osi-west.es.net via ESnet SMTP service id <02773-0@osi-west.es.net>; Fri, 24 Jun 1994 06:56:22 +0000 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA15785; Fri, 24 Jun 1994 15:56:05 +0200 Message-Id: <199406241356.AA15785@mitsou.inria.fr> To: Ron Frederick Cc: Thierry Turletti , rem-conf@es.net Subject: Re: Comments requested: RTP version 2 In-Reply-To: Your message of "Thu, 23 Jun 1994 16:30:50 PDT." <94Jun23.163104pdt.16150@ecco.parc.xerox.com> Date: Fri, 24 Jun 1994 15:56:04 +0200 From: Christian Huitema Ron, I beg to disagree with your comment re "unicast reports". Unicast reports have a number of nice particularities, like: * not requesting an additional m-cast spanning tree computation for all of the sources (think of PIM-dense, or M-OSPF...) * fitting well in the case where you do point to point transmission (point to point can be thought of as a degenerated mcast, but there is no group address) * preserving the privacy of receivers - only the source has to know about them, not all the other receivers. I will not comment on the relative difficulty of feedback control based on multicast vs unicast. Suffice to say that at this stage both are experimental. We certainly have a proof of concept done here, for it is deployed and working. It is true that we did not deploy bridges, but I doubt very much that one could not make the ucast stuff work with a bridge. In the unicast case, we need one specific parameter sent by the source to trigger the reporting + parametrize it. As I said, this is still experimental. I guess that what we need is a possibility to test this parameter and play with the reports. Christian Huitema From rem-conf-request@es.net Fri Jun 24 13:17:47 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <03687-0@osi-west.es.net>; Fri, 24 Jun 1994 10:17:26 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14475(4)>; Fri, 24 Jun 1994 10:17:11 PDT Received: from localhost by ecco.parc.xerox.com with SMTP id <16150>; Fri, 24 Jun 1994 10:17:05 -0700 To: Thierry.Turletti@sophia.inria.fr cc: rem-conf@es.net Subject: Re: Comments requested: RTP version 2 In-reply-to: Your message of "Fri, 24 Jun 94 01:14:42 PDT." <199406240814.AA18258@jerry.inria.fr> X-Mailer: exmh version 1.4 6/23/94 Date: Fri, 24 Jun 1994 10:16:51 PDT Sender: Ron Frederick From: Ron Frederick Message-Id: <94Jun24.101705pdt.16150@ecco.parc.xerox.com> In message <199406240814.AA18258@jerry.inria.fr> you write: > We hope our scalable congestion control scheme resolve this issue. More > experiments are still required but preliminary results are cheering. I don't > want to impose this scheme, I only hope to use the new RTP to test it > further. > In the face of bridges, it is difficult if not impossible to support the backchannel. The old scheme only worked when you could assume full bidirectional connectivity at each bridge/translator step, which just isn't true in practice (because of firewalls). It also involved some real ugliness when trying to identify senders in a global way, for things such as QOS reports. From what I know about your congestion control scheme, there's nothing about it that relies on unicast. As long as you really do keep the total traffic down to much less than a typical media stream, the overhead of multicasting the reports is small, and it has some distinct advantages for third party monitoring tools. > Hmm. I didn't mean no ``QoS'' reports from receive-only participants but > useless periodic control messages such as SDES ... Sure, we need to have an > estimate of the global network state. I just wanted to consider the case > where the identity and the number of participants in the conference is large > and unknown; I didn't see any hook in RTP. > The current proposal doesn't require full SDES information to be sent by all receivers. It currently does require CNAME information, so that there's some sort of meaningful name associated with the sender of each QOS report, but other SDES information need not be sent. > Oops, I mixed up FMT and APP specific option. Is there any way to reduce > the APP options overhead ? > The APP option is sent inside RTCP packets, which aren't sent very often. It doesn't strike me as very much overhead as it stands. Anything which was deemed useful for all applications would eventually be converted from an APP option to a regular RTCP payload type, which would save the 4 byte app identifier. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Fri Jun 24 13:32:58 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <03708-0@osi-west.es.net>; Fri, 24 Jun 1994 10:32:41 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14504(8)>; Fri, 24 Jun 1994 10:32:32 PDT Received: from localhost by ecco.parc.xerox.com with SMTP id <16150>; Fri, 24 Jun 1994 10:32:22 -0700 To: Christian Huitema cc: Thierry Turletti , rem-conf@es.net Subject: Re: Comments requested: RTP version 2 In-reply-to: Your message of "Fri, 24 Jun 94 06:56:04 PDT." <199406241356.AA15785@mitsou.inria.fr> X-Mailer: exmh version 1.4 6/23/94 Date: Fri, 24 Jun 1994 10:32:14 PDT Sender: Ron Frederick From: Ron Frederick Message-Id: <94Jun24.103222pdt.16150@ecco.parc.xerox.com> In message <199406241356.AA15785@mitsou.inria.fr> you write: > I beg to disagree with your comment re "unicast reports". Unicast reports > have a number of nice particularities, like: > > * not requesting an additional m-cast spanning tree computation for > all of the sources (think of PIM-dense, or M-OSPF...) > This is true, but that's assuming that there _is_ a unicast backchannel available. As I pointed out in a message to Thierry, that is simply not the case in many situations because of firewalls that have been designed to allow multicast through but not to allow unicast. By using only one mechanism for both data & reporting, it is much more likely to be the case that anyone who can participate in the conference can participate in the reporting. > * fitting well in the case where you do point to point transmission (point > to point can be thought of as a degenerated mcast, but there is no group > address) > In the point to point case, the two schemes are identical. In place of the group address, you have to specify the address of the other host, and so a report packet generated to the "forward" channel is a unicast to the other host, just like data packets. > * preserving the privacy of receivers - only the source has to know about > them, not all the other receivers. > This is weak privacy at best, unless you involve encryption. > I will not comment on the relative difficulty of feedback control based > on multicast vs unicast. Suffice to say that at this stage both are > experimental. We certainly have a proof of concept done here, for it is > deployed and working. It is true that we did not deploy bridges, but I doubt > very much that one could not make the ucast stuff work with a bridge. > Bridges are the key, though. I would certainly be interested in hearing detailed proposals for how to make a unicast scheme work cleanly through bridges and translators. The previous scheme we had in RTPv1 was a mess for a number of reasons. The fact is that a large number of sites are going to be using bridges or translators for some reason, and a scheme which thinks of them as rare is likely to cause problems. > In the unicast case, we need one specific parameter sent by the source > to trigger the reporting + parametrize it. As I said, this is still > experimental. I guess that what we need is a possibility to test this > parameter and play with the reports. > The major change in RTPv2 is that we decided we wanted a QOS reporting scheme that wasn't just experimental (and different in each application, if it was present at all). The one way we knew worked well was the forward channel multicast-based approach, and so that's what we made part of the design. I'm not saying that experimentation with unicast based reporting should stop. However, I am saying that I don't think that the RTP design should be encumbered by a poor unicast backchannel scheme that adds a lot of complexity and doesn't work in practice. That's what we would have if we tried to keep something like the RTPv1 design, and I haven't heard of any alternative proposals. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Fri Jun 24 14:41:40 1994 Received: from media-lab.media.mit.edu by osi-west.es.net via ESnet SMTP service id <04071-0@osi-west.es.net>; Fri, 24 Jun 1994 11:41:08 +0000 Received: by media.mit.edu (5.57/DA1.0.4.amt) id AA11744; Fri, 24 Jun 94 14:41:04 -0400 Date: Fri, 24 Jun 94 14:41:04 -0400 From: david "k." young Message-Id: <9406241841.AA11744@media.mit.edu> To: rem-conf@es.net Subject: Unsubscribe me Please unsubscribe me from this mailing list. Sorry for sending this to the list but I tried sending to rem-conf-request with no success. From rem-conf-request@es.net Fri Jun 24 21:00:24 1994 Received: from ntrlink.hq.interlink.com by osi-west.es.net via ESnet SMTP service id <05562-0@osi-west.es.net>; Fri, 24 Jun 1994 18:00:04 +0000 Received: from pluto.hq.interlink.com by ntrlink.hq.interlink.com with SMTP id AA18370 (5.64+/IDA-1.3.4-901124 for rem-conf@es.net); Fri, 24 Jun 94 17:56:44 -0700 Received: by pluto.hq.interlink.com (AIX 3.2/UCB 5.64/4.03) id AA13979; Fri, 24 Jun 1994 17:57:09 -0700 Date: Fri, 24 Jun 1994 17:57:09 -0700 From: leela@pluto.hq.interlink.com (Leela Padmanaban) Message-Id: <9406250057.AA13979@pluto.hq.interlink.com> To: rem-conf@es.net Subject: subscribe add leela@interlink.com From rem-conf-request@es.net Sat Jun 25 00:04:03 1994 Received: from helix.mgh.harvard.edu by osi-west.es.net via ESnet SMTP service id <05859-0@osi-west.es.net>; Fri, 24 Jun 1994 21:03:38 +0000 Received: from atdt.l0pht.com by HELIX.MGH.HARVARD.EDU (PMDF #5571 ) id <01HDXTGYHXNK8WWA24@HELIX.MGH.HARVARD.EDU>; Sat, 25 Jun 1994 00:02:40 EST Date: 24 Jun 1994 23:58:19 -0700 (PDT) From: lester@HELIX.MGH.HARVARD.EDU Subject: subscribe To: rem-conf@es.net, mbone@isi.edu Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. subscribe Please add me to the mailing list... thank you.. ------------------------------------- John Lester - Systems Specialist/Manager Massachusetts General Hospital Department of Neurology Neurology Research Boston, MA E-mail: Lester@helix.mgh.harvard.edu (John Lester) World Wide Web: http://132.183.145.103 Date: 06/24/94 Time:23:58:19 "The Computer is like an Old Testament God... a lot of rules, and no mercy." This message was sent by Chameleon ------------------------------------- From rem-conf-request@es.net Mon Jun 27 03:36:08 1994 Received: from ceres.fokus.gmd.de by osi-west.es.net via ESnet SMTP service id <11269-0@osi-west.es.net>; Mon, 27 Jun 1994 00:35:43 +0000 Received: from fokus.gmd.de by ceres.fokus.gmd.de id <09922-0@ceres.fokus.gmd.de>; Mon, 27 Jun 1994 09:36:17 +0200 To: frederic@parc.xerox.com Subject: Re: Comments requested: RTP version 2 Cc: rem-conf@es.net Date: Mon, 27 Jun 1994 09:36:17 +0200 From: Henning Schulzrinne Sender: schulzrinne@fokus.gmd.de > > In message <199406241356.AA15785@mitsou.inria.fr> you write: > > I beg to disagree with your comment re "unicast reports". Unicast reports > > have a number of nice particularities, like: > > > > * not requesting an additional m-cast spanning tree computation for > > all of the sources (think of PIM-dense, or M-OSPF...) > > > This is true, but that's assuming that there _is_ a unicast backchannel > available. As I pointed out in a message to Thierry, that is simply not the > case in many situations because of firewalls that have been designed to allow > multicast through but not to allow unicast. By using only one mechanism for > both data & reporting, it is much more likely to be the case that anyone who > can participate in the conference can participate in the reporting. Unfortunately, the AT&T firewall is multicast and one-directional. I very much doubt that Steve Bellovin is going to allow outbound multicast. (Open Sun microphones come to mind, plus the untraceable distribution of files by that neat new multicast tool somebody within AT&T happens to pick up, accidental leakage of internal conferences, etc.). Unicast distribution of feedback may be easier to arrange for, but I haven't discussed this. Thus, I doubt this is an argument either way. Henning From rem-conf-request@es.net Mon Jun 27 04:29:09 1994 Received: from mitsou.inria.fr by osi-west.es.net via ESnet SMTP service id <11406-0@osi-west.es.net>; Mon, 27 Jun 1994 01:28:33 +0000 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA26113; Mon, 27 Jun 1994 10:24:30 +0200 Message-Id: <199406270824.AA26113@mitsou.inria.fr> To: Ron Frederick Cc: rem-conf@es.net Subject: Re: Comments requested: RTP version 2 In-Reply-To: Your message of "Fri, 24 Jun 1994 10:32:14 PDT." <94Jun24.103222pdt.16150@ecco.parc.xerox.com> Date: Mon, 27 Jun 1994 10:24:29 +0200 From: Christian Huitema => In message <199406241356.AA15785@mitsou.inria.fr> you write: => > I beg to disagree with your comment re "unicast reports". Unicast reports => > have a number of nice particularities, like: => > => > * not requesting an additional m-cast spanning tree computation for => > all of the sources (think of PIM-dense, or M-OSPF...) => > => This is true, but that's assuming that there _is_ a unicast backchannel => available. As I pointed out in a message to Thierry, that is simply not the => case in many situations because of firewalls that have been designed to allow => multicast through but not to allow unicast. By using only one mechanism for => both data & reporting, it is much more likely to be the case that anyone who => can participate in the conference can participate in the reporting. Well, my opinion here is quite simple: this is a broken way to design a firewall. What you are saying is that you don't want to open a hole the size of a pin (point to point to source), so you open a breach the size of a whale (allow multicast through). I guess that if you really want to do a firewall, you have to do it either at the application layer, in which case the reports will be sent to the firewall and a summary of them from the firwall to the source, or at the network layer, in which case you will allow specific network directions (source/dest pairs) after proper authentication (a la ipsec). => => > * fitting well in the case where you do point to point transmission (point => > to point can be thought of as a degenerated mcast, but there is no group => > address) => > => In the point to point case, the two schemes are identical. In place of the => group address, you have to specify the address of the other host, and so a => report packet generated to the "forward" channel is a unicast to the other => host, just like data packets. The difference is not large, but there is a difference. => => > * preserving the privacy of receivers - only the source has to know about => > them, not all the other receivers. => > => This is weak privacy at best, unless you involve encryption. Uh? if a source broadcast a report, then all other recipients know that this source is listening. => => > I will not comment on the relative difficulty of feedback control based => > on multicast vs unicast. Suffice to say that at this stage both are => > experimental. We certainly have a proof of concept done here, for it is => > deployed and working. It is true that we did not deploy bridges, but I doubt => > very much that one could not make the ucast stuff work with a bridge. => > => Bridges are the key, though. I would certainly be interested in hearing => detailed proposals for how to make a unicast scheme work cleanly through => bridges and translators. The previous scheme we had in RTPv1 was a mess for => a number of reasons. => => The fact is that a large number of sites are going to be using bridges or => translators for some reason, and a scheme which thinks of them as rare is => likely to cause problems. Most of the difficulties that you mention come from a specific model of bridges that would allow multicast to pass through without looking at the content. The problem don't exist if you have an "application relay". I have some extreme doubts on the real security of allowing "multicast" to pass through without further looking at it! => > In the unicast case, we need one specific parameter sent by the source => > to trigger the reporting + parametrize it. As I said, this is still => > experimental. I guess that what we need is a possibility to test this => > parameter and play with the reports. => > => The major change in RTPv2 is that we decided we wanted a QOS reporting scheme => that wasn't just experimental (and different in each application, if it was => present at all). The one way we knew worked well was the forward channel => multicast-based approach, and so that's what we made part of the design. => => I'm not saying that experimentation with unicast based reporting should stop. => However, I am saying that I don't think that the RTP design should be => encumbered by a poor unicast backchannel scheme that adds a lot of complexity => and doesn't work in practice. That's what we would have if we tried to keep => something like the RTPv1 design, and I haven't heard of any alternative => proposals. Well, I believe it is way to early to cast the QOS formats in the marble. Christian Huitema From rem-conf-request@es.net Mon Jun 27 10:33:45 1994 Received: from animal.cs.chalmers.se by osi-west.es.net via ESnet SMTP service id <12631-0@osi-west.es.net>; Mon, 27 Jun 1994 07:33:24 +0000 Date: Mon, 27 Jun 94 16:32:12 +0200 From: Gunnar Lindberg Message-Id: <9406271432.AA17567@animal.cs.chalmers.se> Received: from wilferc.cs.chalmers.se by animal.cs.chalmers.se (5.60+IDA/3.14+gl) id AA17567; Mon, 27 Jun 94 16:32:12 +0200 Received: by wilferc.cs.chalmers.se (5.60+IDA/3.14+gl) id AA00566; Mon, 27 Jun 94 16:32:12 +0200 To: ljb@merit.edu Subject: Re: vat and Solaris 1.1.1 on Sparc 5's Cc: Jack.Jansen@cwi.nl, casner@isi.edu, deering@parc.xerox.com, frederic@parc.xerox.com, mccanne@ee.lbl.gov, rem-conf@es.net, van@ee.lbl.gov >: > ARGHH. Looks like I spoke too soon. There still seems to be a few >problems with the driver. First, whenever there is audio output >there are frequent loud "pops" in the output. Second, after running with >a continuous audio stream for awhile (with a Radio Free Vat session), >the driver spits out the following messages to the console: >DMA_SETUP failed in play! >DMA_SETUP failed in play! >DMA_SETUP failed in record! >DMA_SETUP failed in record! > then the machine enters a semi-hung state requiring a L1-A and >a reboot. I've tried this twice (once with audio_4231_bsize >changed to 160 and once without) and the same thing happened both >times. Well, it seems like there has to be more to it than just an audio stream. I run BBC1 for something like 3 hours whithout problems (except BBC1 music taste doesn't match mine :-). Then I started a second vat session and - ooops - machine hung => "L1 A". It seems like things go wrong whenever there is race condition for the device, like 2 users (vat sessions) or "Release / Keep". > Looks like this isn't quite ready for prime-time. Hopefully someone has good connections with Sun, good enough to make them fix it in SunOS4.1.3 and not only in Solaris2 (which I`ve been told also has problems with the 4231 audio). We don't have enough Sun:s (6-700 isn't that many) and Sweden isn't big enough to be important enough for such a bug report from here. Gunnar Lindberg From rem-conf-request@es.net Mon Jun 27 12:37:10 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <13205-0@osi-west.es.net>; Mon, 27 Jun 1994 09:36:52 +0000 Received: from zeus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 27 Jun 1994 17:35:59 +0100 To: rem-conf@es.net Cc: research@cs.ucl.ac.uk Subject: Mice seminar Date: Mon, 27 Jun 94 17:35:58 +0100 From: Roy Bennett The next seminar in the current series will be multicast over Mbone on Thursday next, June 30,1994. Details as follows (and also in URL http://ww.cs.ucl.ac.uk/mice/seminars/ ) Date: June 30,1994 Time: 18:00 to 19:30 GMT Subject: Filesystem Stacks for 4.4 Bsd Lite Speaker: Jan-Simon Pendry (Sequent) Synopsis: Filesystem stacking is a new facility in 4.4 Bsd Lite. It can be used in many different ways, from creating `writable' CD-ROMS through in-place automounting to per-user views of the filesystem. The concept is simple though the implementation is not so simple... This seminar is held in conjunction with the London UNIX Users Group. The seminar video will be transmitted using IVS 3.3m2 Versions are available from ftp://ftp.ucs.ed.ac.uk/pub/videoconference/ivs/ Transmission details: Address: 224.5.17.12 Ports: vat 3456 ivs 2232 wb 32416 An entry will be made in SD on Wednesday. Enquiries/comments to me please. Roy --------------------------------------------------------------------- Roy Bennett Email: rbennett@cs.ucl.ac.uk Computer Science University College London Phone: +44 71 380 7777 x3683 Gower Street, LONDON WC1E 6BT Fax: +44 71 387 1397 --------------------------------------------------------------------- From rem-conf-request@es.net Mon Jun 27 22:59:22 1994 Received: from mcl.cc.utexas.edu by osi-west.es.net via ESnet SMTP service id <16827-0@osi-west.es.net>; Mon, 27 Jun 1994 19:58:55 +0000 Received: from [128.83.128.58] (slip-8-10.ots.utexas.edu [128.83.128.58]) by mcl.cc.utexas.edu (8.6.8.1/8.6.6/mcl.mc-1.1) with SMTP id VAA26873 for ; Mon, 27 Jun 1994 21:58:13 -0500 Message-Id: <199406280258.VAA26873@mcl.cc.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Jun 1994 09:57:49 -0700 To: rem-conf@es.net From: swilson@mcl.cc.utexas.edu (Steve Wilson) unsubscribe swilson@mcl.cc.utexas.edu From rem-conf-request@es.net Mon Jun 27 23:39:05 1994 Received: from mcl.cc.utexas.edu by osi-west.es.net via ESnet SMTP service id <16952-0@osi-west.es.net>; Mon, 27 Jun 1994 20:38:39 +0000 Received: from [128.83.128.58] (slip-8-10.ots.utexas.edu [128.83.128.58]) by mcl.cc.utexas.edu (8.6.8.1/8.6.6/mcl.mc-1.1) with SMTP id WAA29099 for ; Mon, 27 Jun 1994 22:37:58 -0500 Message-Id: <199406280337.WAA29099@mcl.cc.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Jun 1994 10:37:33 -0700 To: rem-conf@es.net From: swilson@mcl.cc.utexas.edu (Steve Wilson) unsubscribe Steve Wilson From rem-conf-request@es.net Tue Jun 28 00:20:39 1994 Received: from ucsd.edu by osi-west.es.net via ESnet SMTP service id <17306-0@osi-west.es.net>; Mon, 27 Jun 1994 21:20:13 +0000 Received: from sdcc3.UCSD.EDU by ucsd.edu; id VAA25905 sendmail 8.6.9/UCSD-2.2-sun via SMTP Mon, 27 Jun 1994 21:20:10 -0700 for Received: by sdcc3.UCSD.EDU (4.1/UCSDGENERIC.3) id AA10292 to rem-conf@es.net; Mon, 27 Jun 94 21:20:09 PDT Date: Mon, 27 Jun 94 21:20:09 PDT From: mu299ac@sdcc3.UCSD.EDU (\(null\)) Message-Id: <9406280420.AA10292@sdcc3.UCSD.EDU> To: rem-conf@es.net Subject: unsubscribe please unsubscribe mu299ac@sdcc3.ucsd.edu It's been fabulous! From rem-conf-request@es.net Tue Jun 28 01:13:52 1994 Received: from ns.infinet.com by osi-west.es.net via ESnet SMTP service id <17738-0@osi-west.es.net>; Mon, 27 Jun 1994 22:13:15 +0000 Received: from nitelog by mail.infinet.com with uucp (Smail3.1.28.1 #9) id m0qIVUs-000DMzC; Tue, 28 Jun 94 01:14 EDT Received: by nitelog (PCBuucp 2.0) with UUCP id D05312; Mon, 27 Jun 94 22:05:41 -0800 To: rem-conf-request@es.net, rem-conf@es.net Subject: unsubscribe From: kim.cohan@nitelog.com (Kim Cohan) Message-ID: Date: Mon, 27 Jun 94 21:12:00 -0800 Organization: Nitelog BBS - Monterey, CA - 408-655-1096 unsubscribe From rem-conf-request@es.net Tue Jun 28 02:57:06 1994 Received: from ceres.fokus.gmd.de by osi-west.es.net via ESnet SMTP service id <18742-0@osi-west.es.net>; Mon, 27 Jun 1994 23:56:41 +0000 Received: from fokus.gmd.de by ceres.fokus.gmd.de id <11014-0@ceres.fokus.gmd.de>; Tue, 28 Jun 1994 08:57:32 +0200 To: rem-conf@es.net Subject: RTP: unicast/multicast feedback Date: Tue, 28 Jun 1994 08:57:32 +0200 From: Henning Schulzrinne Sender: schulzrinne@fokus.gmd.de I must be missing something, but I fail to see how the proposed choice of globally unique random ids prevents falling back on unicast feedback, if this should be desirable for certain situations where a full N-by-N multicast mesh is too expensive or not feasible. There are two cases: 1) (a suitably selected subset of) receivers report back to single monitor different from the sender(s); the address of this monitor could easily be conveyed out-of-band. The packet format would probably contain the sender SSRC or CNAME for identification and some set of QOS parameters. Senders can easily be identified, even if several different protocol stacks happen to be in use. Receiver identification probably has to use CNAME rather than SSRC, since receivers cannot generate a unique random id due to lack of collision detection mechanism. 2) (subset of) receivers report back to the sender (bridge or plain source). A media receiver would reverse the UDP address and port (or use the RTCP port). Packets would contain the SSRC or CNAME for identification. Reports would (typically) stop at bridges, just like they do now; translators would have to keep a mapping from CNAME or SSRC to network address, without having to assign new identifiers - not a very onerous task (a simple hash table). It appears that these facilities can be added in a backward compatible manner after experimentation, with the exception of having to add the lookup table mechanism to the translator. We seem to have identified as least two scaling methods: random sampling of receivers and increasing feedback period. The former scales to any population size, just like opinion surveys; the latter starts to loose its usefulness as the sampling period approaches tens of seconds. (Typical high-accuracy surveys seem to have a sample size of a few thousand, which also is probably a reasonable upper bound on the second kind of scaling.) Comments? Henning From rem-conf-request@es.net Tue Jun 28 08:07:04 1994 Received: from philabs.philips.com by osi-west.es.net via ESnet SMTP service id <20377-0@osi-west.es.net>; Tue, 28 Jun 1994 05:06:38 +0000 Received: from mars.Philabs.Philips.Com by philabs.Philips.COM (smail2.5/12-15-87/4.1) id AA25262; Tue, 28 Jun 94 08:06:35 EDT Received: by mars.Philabs.Philips.Com (4.1/SMI-4.1) id AA01430; Tue, 28 Jun 94 08:06:33 EDT Date: Tue, 28 Jun 94 08:06:33 EDT From: jec@philabs.Philips.COM (Jorge E. Caviedes) Message-Id: <9406281206.AA01430@mars.Philabs.Philips.Com> To: rem-conf@es.net Subject: Session participants required Cc: brf@mars, jec@mars Hi all, Here at Philips Labs we have a yearly visit of local science teachers to bring them up to date with new tecnologies and help them get started with current educational tools. As part of a session on Internet, we would like to demonstrate videoconferencing over the Mbone. We intend to have a session (worldwide if possible) at 2:00PM EST on July 11. Duration will be 30min to 1hr. I am interested in finding people who may be interested in participating, chatting with science teachers, and perhaps answering their questions about Internet. Let me know if you are interested, or have any suggestions or comments, thanks, Jorge Caviedes Sr. Member Research Staff Philips Laboratories Briarcliff Manor, NY From rem-conf-request@es.net Tue Jun 28 13:52:18 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <22166-0@osi-west.es.net>; Tue, 28 Jun 1994 10:51:56 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14492(2)>; Tue, 28 Jun 1994 10:51:35 PDT Received: from localhost by ecco.parc.xerox.com with SMTP id <16150>; Tue, 28 Jun 1994 10:51:32 -0700 To: Christian Huitema cc: rem-conf@es.net Subject: Re: Comments requested: RTP version 2 In-reply-to: Your message of "Mon, 27 Jun 94 01:24:29 PDT." <199406270824.AA26113@mitsou.inria.fr> X-Mailer: exmh version 1.4 6/24/94 Date: Tue, 28 Jun 1994 10:51:19 PDT Sender: Ron Frederick From: Ron Frederick Message-Id: <94Jun28.105132pdt.16150@ecco.parc.xerox.com> In message <199406270824.AA26113@mitsou.inria.fr> you write: > Well, my opinion here is quite simple: this is a broken way to design a > firewall. What you are saying is that you don't want to open a hole the size > of a pin (point to point to source), so you open a breach the size of a whale > (allow multicast through). I guess that if you really want to do a firewall, > you have to do it either at the application layer, in which case the reports > will be sent to the firewall and a summary of them from the firwall to the > source, or at the network layer, in which case you will allow specific > network directions (source/dest pairs) after proper authentication (a la > ipsec). > I never claimed any such thing. I simply said that by using the same mechanism to deliver both data and report information, you were more likely to get it through a firewall than if you used two different mechanisms. The hole can be as small as you like (multicasts from a particular internal host to a particular multicast group). If you involve two mechanisms, it can still be done, but it most certainly going to be harder. Henning pointed out that there may be firewalls which let multicast traffic in but not out. That's certainly true -- but someone at such a site cannot participate in the conference at all. If they arrange for an application level bridge to allow them to participate, the same exact mechanism in the bridge which gets their data packets out can be used to get their report packets out. That would not be the case for unicast reporting. > Most of the difficulties that you mention come from a specific model of > bridges that would allow multicast to pass through without looking at the > content. The problem don't exist if you have an "application relay". I have > some extreme doubts on the real security of allowing "multicast" to pass > through without further looking at it! > Not at all. The bridges I was assuming were application level bridges, even doing things like mixing & retiming the data. However, the fact remains that the old design made bridges a _lot_ more complicated, and made some strange assumptions about the fact that multicast connectivity implied reverse unicast connectivity. The old design also had a serious problem globally identifying sources in a clean way. > Well, I believe it is way to early to cast the QOS formats in the marble. > I agree with you that the research is not finished, but I think the time has definitely come for SOME form of QOS reporting to be a mandatory part of the applications on the MBONE, and I think this multicast reporting scheme is the only one we have any significant operational experience with, so it is the natural choice. I don't have a problem with changing the scheme in a future version of RTP once we know more. As for how to accomplish the research within RTPv2, I agree with Henning's latest message about that. The global SSRC identifiers actually make it easier to do both unicast and multicast reporting. If you want the unicast backchannel to work through bridges and translators, you will need to add some code to them that isn't required by RTPv2 itself, but that's fine for experimentation. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Tue Jun 28 18:48:59 1994 Received: from atlas.arc.nasa.gov by osi-west.es.net via ESnet SMTP service id <23871-0@osi-west.es.net>; Tue, 28 Jun 1994 15:48:41 +0000 Received: from atlas.arc.nasa.gov by atlas.arc.nasa.gov id <22869-0@atlas.arc.nasa.gov>; Tue, 28 Jun 1994 15:48:21 -0700 From: Nora Lavelle Message-Id: <9406281548.ZM22861@atlas.arc.nasa.gov> Date: Tue, 28 Jun 1994 15:48:14 -0700 X-Mailer: Z-Mail (3.0.1 04apr94) To: rem-conf@es.net Subject: Nasa Shuttle STS-65 Broadcast Cc: anaops@atlas.arc.nasa.gov Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: nlavelle@atlas.arc.nasa.gov It's that time once again! I am planning to multicast the NASA Select coverage of STS-65 on a 24 hour basis starting on July 8, 1994 and lasting until July 22, 1994. This coverage will consist of nv and vat sessions. If this coverage interferes with other multicast conferences, I will be standing by to reduce bandwidth or suspend coverage in order to share the MBONE. I will be multicasting with a ttl of 127. If there are any problems with this schedule or practice, please contact me. E-mail all questions or comments to anaops@atlas.arc.nasa.gov Thanks! -------------------------------------------------------------------------------- Nora Lavelle System Adminstrator Sterling Software NASA Ames Research Center nlavelle@atlas.arc.nasa.gov -------------------------------------------------------------------------------- From rem-conf-request@es.net Wed Jun 29 13:51:49 1994 Received: from email.univie.ac.at by osi-west.es.net via ESnet SMTP service id <28073-0@osi-west.es.net>; Wed, 29 Jun 1994 10:51:25 +0000 Received: from ravel.ifs.univie.ac.at by email.univie.ac.at with SMTP (PP) id <29703-0@email.univie.ac.at>; Wed, 29 Jun 1994 19:49:55 +0200 Received: from (liszt.ifs.univie.ac.at) by ifs.univie.ac.at (4.1/SMI-4.3.12) id AA12284; Wed, 29 Jun 94 19:49:52 +0200 Date: Wed, 29 Jun 94 19:49:52 +0200 From: tjoa@ifs.univie.ac.at (A Min Tjoa) Message-Id: <9406291749.AA12284@ifs.univie.ac.at> To: azhao@cc.gatech.edu, luphouh@engin.umich.edu, corth@CNRI.Reston.VA.US, rem-conf@es.net, "Matti.Aarnio.mea" <@uu5.psi.com:Matti.Aarnio.mea@nic.funet.fi.HOPPERS%uu1072> Subject: E N T E R '95 Cc: amt@email.univie.ac.at azhao@cc.gatech.edu ----- Begin Included Message ----- From tjoa Wed Jun 29 18:59:44 1994 Return-Path: Received: from (liszt.ifs.univie.ac.at) by ifs.univie.ac.at (4.1/SMI-4.3.12) id AA12004; Wed, 29 Jun 94 18:59:44 +0200 Date: Wed, 29 Jun 94 18:59:44 +0200 From: tjoa (A Min Tjoa) Message-Id: <9406291659.AA12004@ifs.univie.ac.at> To: amt Subject: E N T E R '95 Content-Length: 5194 X-Lines: 109 Status: RO CALL FOR PAPERS (E N T E R '95) 2nd International Conference on Information and Communications Technology in the Field of Tourism - ENTER 95 _________________________________________________________________________ January 18th - 20th 1995 Innsbruck, Austria CONFERENCE OBJECTIVES: ENTER `95 is intended to be an international forum dealing with the use and development of information systems and communication technologies in the domain of tourism and leisure time. Information and communication systems embedded in a global net have profound influence on the tourism and leisure industry and will alter it considerably. Reservation systems, distributed multi-media systems, highly mobile working places, so-called "electronic markets" are the first noticeable results of this development. Advances in the use and development of tools, technologies and methodologies that have facilitated the efficient netting of information and communication systems in the tourism industry are to be presented and discussed within ENTER. Apart from scientific and technical sessions the conference offers additional tutorials, workshops and presentations for practitioners in the area of tourism. ENTER is directed towards two target groups: system developers and practitioners which are actively involved in the field of touristic information technology and methodology as well as system users and practicians interested in a further discussion of the subject. Both these groups will be offered joint presentations to facilitate and support communication. ENTER represents the first international forum of this kind and is intended to held in regular intervals. Each of these conferences will be headed by a general topic which will especially be dealt with by the presentations for the practitioners. The general topic for 1995 is entitled electronic marketing. SUGGESTED TOPICS: Contributions in the scientific and technical range will cover the following areas: - Information systems - enterprise modelling - expert systems - decision support systems - multi-media - capacity management - distributed systems - WAN's - system architectures - reservation systems - management information systems - optimization and simulation models - reverse marketing - management / organization / business and national economical aspects - virtual reality and tourism - quality control in tourism - legal aspects as well as other areas concerned with information technology in tourism. INSTRUCTION TO AUTHORS: The conference languages will be German and English. Contribution to the conference in the form of papers are to be submitted exclusively in English. Papers are invited on the topics listed and others within the general theme of the conference. Four copies of abstracts of no more than 1000 words should be submitted by July 31st 1994 to the Program Chair: Prof. Dr. A Min Tjoa, Institute of Applied Computer Science and Information Systems, University of Vienna, Liebiggasse 4, A- 1010 Vienna, Austria Abstracts should clearly state the purpose, results and conclusions of the work to be described in the final paper. Authors of accepted abstracts will be notified by September 15th 1994. The category designation from the list of topics and final acceptance will be based upon review of the full length paper, which must be received by November 1st, 1994. All papers received will be refereed by an International Program Committee and each paper will be reviewed by independent referees. Accepted papers will be published in the proceedings (Springer Verlag) to be distributed to the participants at the conference. TIME SCHEDULE: Submit abstract (1000 Words) July 31st, 1994 Preliminary acceptance September 15th, 1994 Submit final paper November 1st, 1994 Program Committee / Co-Chairs: TJOA A Min University of Vienna, Austria, Scientific and Technical Range WERTHNER Hannes University of Vienna, Austria Application Oriented Range SCHMID Beat University of St. Gallen, Switzerland SCHERTLER Walter University of Trier, Germany Program Committee members: AIVALIS Constantin University of Crete, Greece BAUKNECHT Kurt University of Zürich, Switzerland BRANDES Wolfram P. Arthur D. Little, Germany EBNER Arno TIS GmbH, Austria HITZ Martin University of Vienna, Austria JAFAR Jafari University of Wisconsin, USA KASPAR Claude University of St. Gallen, Switzerland KUBICEK H. University of Bremen, Germany MAARTMANN-MOE Erling Norwegian Computing Center, Norway MATA-MONTERO Erick Instituto Tecnólogico de Costa Rica MAZANEC Josef A. University of Vienna, Austria MEIJS Chris Wageningen Agricultural University, The Netherlands OSTROWSKI Doreen Travel Trust International, Canada PAOLINI Paolo Politecnico di Milano, Italy PERONI Giovanni CST Perugia, Italy REVEL Norman City University of London, Great Britain RIBBERS Pieter Tilburg University, The Netherlands ROITHMAYR F. University of Innsbruck, Austria SHELDON P. University of Hawaii, USA STOCK Oliviero Istituto per la Ricerca Scientifica e Tecnologica, Italy WAGNER Roland University of Linz, Austria WEIERMAIR Klaus University of Innsbruck, Austria WIETRZYK Vlad University of Technology Sydney, Australia ----- End Included Message ----- From rem-conf-request@es.net Wed Jun 29 19:26:06 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <00238-0@osi-west.es.net>; Wed, 29 Jun 1994 16:25:49 +0000 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14420(7)>; Wed, 29 Jun 1994 16:25:33 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 29 Jun 1994 16:25:30 -0700 To: rem-conf@es.net cc: deering@parc.xerox.com Subject: PARC Forum talk, June 30: Programming as a Video Game Date: Wed, 29 Jun 1994 16:25:25 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jun29.162530pdt.12171@skylark.parc.xerox.com> We expect to transmit audio and video of the following talk on the MBone tomorrow (Thursday, June 30) at 4:00 pm PDT (2300 GMT), It will be advertised in sd under the names "Xerox PARC Forum - Audio" and "Xerox PARC Forum - Video". Steve ---------- PARC Forum Date: Thursday, 30th June 1994 Time: 4:00pm-5:00pm Place: PARC Auditorium, Xerox PARC, 3333, Coyote Hill Road, Palo Alto CA 94304 Speaker: Dr. Ken Kahn, Animated Programs _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ PROGRAMMING AS A VIDEO GAME _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ by Dr. Ken Kahn Animated Programs Programming is usually thought of as an activity that involves entering program text and then compiling and executing that text. The process of learning to program typically involves textbooks, manuals and teachers. Video games are very different: there is rarely any typing; manuals are minimal and usually not read; a player learns how to succeed in the game from experimentation, practice, and talking to friends. Even those who love to program do not find the "mechanics" of programming, i.e., typing in text, dealing with syntax errors, etc., to be fun. In contrast, the "mechanics" of playing a video game (e.g., sword fighting) is fun as well as the higher level game play. I'll present and demo a programming system, ToonTalk (TM) with the "look and feel" of a video game. ToonTalk is a video game for constructing general purpose programs (including video games) in an easy to learn and fun manner. ----------------------------------------------------------------------------- This Forum is OPEN to the Public. All are invited to attend. Refreshments will be served at 3:45 p.m. The PARC auditorium is located at 3333 Coyote Hill Road in Palo Alto. We are between Page Mill Road (West of Foothill Expressway) and Hillview Avenue, in the Stanford Research Park. From Page Mill Road, turn onto Coyote Hill Road. Drive Up Coyote Hill past the horse pastures; PARC is the only building on the left, just past the crest of the hill. Due to some construction in our main parking lot, please park in the lot across Coyote Hill Road. Cross the street and enter the auditorium at the upper level of the building. The auditorium entrance is located down the stairs and to the left of the main doors from the outside of the building. Upcoming Forum: 7th July: Joint Venture Silicon Valley Title to be announced (this Forum will be OPEN to the public - all are invited to attend) From rem-conf-request@es.net Thu Jun 30 08:24:55 1994 Received: from mwunix.mitre.org by osi-west.es.net via ESnet SMTP service id <02537-0@osi-west.es.net>; Thu, 30 Jun 1994 05:24:29 +0000 Return-Path: zakon@hobbes.mitre.org Received: from hobbes.mitre.org (hobbes.mitre.org [128.29.33.43]) by mwunix.mitre.org (8.6.4/8.6.4) with SMTP id IAA27567 for ; Thu, 30 Jun 1994 08:24:25 -0400 Received: by hobbes.mitre.org (5.0/SMI-SVR4) id AA10097; Thu, 30 Jun 1994 08:18:33 +0500 Date: Thu, 30 Jun 1994 08:18:33 +0500 From: zakon@hobbes.mitre.org (Robert H'obbes' Zakon) Message-Id: <9406301218.AA10097@hobbes.mitre.org> To: rem-conf@es.net Subject: August 4 Mbone Broadcast X-Sun-Charset: US-ASCII content-length: 6323 ****************** MBONE BROADCAST -- ADVANCED NOTICE ****************** We would like to transmit the SIGNIDR Conference sessions on the MBone. SIGNIDR = Special Interest Group on Networked Information Discovery and Retrieval The transmissions will take place on August 4, 1994 for one day only (9:00am to 5:00pm EST). This session will be advertised on SD closer to the date of transmission if acceptable to the Mbone community. Audio and Video will be multicast via NV and VAT. Please respond if this date is in conflict with another transmission. ************************************************************************** SIGNIDR V Preliminary Meeting Announcement Special Interest Group on Networked Information, Discovery, and Retrieval (Previously SIGWAIS, Special Interest Group on Wide Area Information Server) ----------------------------------------------------------------------------- The MITRE Corporation will sponsor the next meeting of the Special Interest Group on Networked Information, Discovery, and Retrieval. General topics of interest for this group are WAIS, gopher, World Wide Web, and other information retrieval and discovery technologies. We are planning for an interesting and exciting meeting. We look forward to seeing you there. This meeting will focus in on three areas: 1. security including firewall issues, 2. electronic publishing and copyright issues, and 3. knowbots and other information discovery technologies. IF YOU WOULD BE INTERESTED IN MAKING A PRESENTATION IN ANY OF THESE AREAS, PLEASE INDICATE THIS ON THE REGISTRATION FORM BELOW AND SEND IT TO US AT "signidr@mitre.org". Date: Thursday, August 4, 1994 Time: 9:00 AM to 5:00 PM Place: The MITRE Corporation 7525 Colshire Drive McLean, VA 22102 Registration: PLEASE REGISTER EARLY TO ASSURE YOUR ATTENDANCE. Space is limited to 300 attendees. Complete registration form below and return by e-mail or fax: e-mail: signidr@mitre.org fax: 703/883-1397 (c/o Lorrayne Schaefer) Fee: None Demos Welcome: If you have a demo you would like to share with your colleagues in our demo area, there is space to indicate this on the registration form; please let us know. Demo selection will be coordinated based on space availability and focus of presentation. Vendors Welcome: We would like to include vendor information and demos at this meeting. If you are a vendor and would like to participate please indicate this in the space provided on the registration form. Selection will be coordinated based on space availability and focus of presentation. Access: Free, on-site, parking at MITRE Corporation. Driving directions to MITRE will appear in a later announcement. Nearest Metro is West Falls Church (orange line) with approximately an $8 taxi ride (~7 minute) from Metro to MITRE. Bus #3B marked "Tyson's Corner" also runs from West Falls Church Metro to the vicinity of MITRE. The fare is $1 and takes about 15 min. plus a short walk from the bus stop. Airport: MITRE is approximately equi-distant from Washington National Airport and Washington Dulles Airport. Travel time from the airports to MITRE is about 25 minutes and taxi cost is approximately $30.00. Nearby Hotels: Best Western Tyson's Westpark 2 miles to MITRE 8401 Westpark Drive McLean, VA 22102 703/734-2800 McLean Hilton at Tyson's Corner 1.5 miles to MITRE 7920 Jones Branch Drive McLean, VA 22102 703/847-5000 Ritz-Carlton, Tyson's Corner .5 miles to MITRE 1700 Tyson's Blvd McLean, VA 22102 703/506-4300 Tyson's Corner Ramada 1 mile to MITRE 7801 Leesburg Pike Falls Church, VA 22043 703/893-1340 Tyson's Corner Marriott 1 mile to MITRE 8028 Leesburg Pike Vienna, VA 22182 800/228-9290 -------------------------Registration Form---------------------------- SIGNIDR V Registration Thursday, August 4, 1994 MITRE CORPORATION McLean, VA Name:___________________________________________________________________ Title:____________________________________________________________________ Affiliation:_____________________________________________________________ Address:__________________________________________________________________ __________________________________________________________________ E-mail:___________________________________________________________________ Phone:_________________________________FAX:______________________________ Which previous SIGNIDR/SIGWAIS have you attended? (Check all that apply.) SIGWAIS I (USGS, Reston, VA) _________ SIGWAIS II (Library of Congress, Wash., DC) _________ SIGNIDR III (Nat. Library of Med., Bethesda, MD) _________ SIGNIDR IV (Dept. of Commerce, Wash., DC) _________ Participant Information: If you wish to participate through a demonstration or vendor display please complete the appropriate information area(s) below. For demos you must supply all equipment you will need, including workstations and other hardware, software, etc. Connections to the Internet will be available. DEMO Name:________________________________________________________________ Demo Description:_________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ VENDOR Name:______________________________________________________________ Description of how you would like to participate:__________________________ ____________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ From rem-conf-request@es.net Thu Jun 30 10:39:58 1994 Received: from mail02.prod.aol.net by osi-west.es.net via ESnet SMTP service id <02995-0@osi-west.es.net>; Thu, 30 Jun 1994 07:39:37 +0000 Received: by mail02.prod.aol.net (1.38.193.5/16.2) id AA24932; Thu, 30 Jun 1994 10:39:33 -0400 From: Scoop4@aol.com X-Mailer: America Online Mailer Sender: Scoop4 Message-Id: <9406301039.tn207341@aol.com> To: rem-conf@es.net Date: Thu, 30 Jun 94 10:39:31 EDT Subject: IEEE802.1 Looking for Guidance Background: The IEEE 802 standardizes Local Area Networks. Current LANs standardized or in development include Ethernet, Token Ring, Token Bus, 100VG-AnyLAN, 100Mbps Ethernet, 10BaseT, et.al. In November of 1993, a new Taskforce was established to propose modifications to existing and future LANs so that they would better support audio and video traffic. The goal of the 802.1 Multimedia Taskforce is to develop an environment for the seamless transport of multimedia traffic on 802 LANs. To that end, WE ARE SOLICITATING MULTIMEDIA LAN REQUIREMENTS, from groups and individuals who ought to have an opinion about such things . A group of individuals stands by to translate these requirements into LLC Requests and Primatives which then will drive the efforts within this International StandardsBody. ***** This in no way conflicts with the efforts of the IETF, in fact, we are actually looking to organizations like the IETF to make sure we are solving the right set of problems. It's been my experience that LAN folks are typically not well versed in Multimedia requirements. YOU CAN HELP>>>A LOT! ( We need all the help we can get!) If you take the time, now, to help us nail down the real issues, the LANs and WANs we develop and you will use in the near future will do a better job of supporting the services you want to provide. DO IT NOW! What is contributed in the next two weeks will be considered for work at the next 802 meeting. (July 12 - Walt Disney Swan Hotel - Orlando FLA) To contribute, please post your requirements to: bw-alloc@hplb.hpl.hp.com Thanks in advance, Stephen W. Cooper Chairman, 802.1 Multimedia Task Force scoop4@aol.com (508) 790-6901 (508) 790-6903 (FAX) From rem-conf-request@es.net Thu Jun 30 11:06:47 1994 Received: from bottom.magnus.acs.ohio-state.edu by osi-west.es.net via ESnet SMTP service id <03072-0@osi-west.es.net>; Thu, 30 Jun 1994 08:06:24 +0000 Received: from [128.146.105.61] by bottom.magnus.acs.ohio-state.edu (8.6.4/4.940426) id LAA21661; Thu, 30 Jun 1994 11:06:18 -0400 Date: Thu, 30 Jun 1994 11:06:18 -0400 Message-Id: <199406301506.LAA21661@bottom.magnus.acs.ohio-state.edu> To: rem-conf@es.net From: sacker@magnus.acs.ohio-state.edu (Steve Acker) Subject: unsubscribe unsubscribe steve acker ____________ Steve Acker Associate Professor Communication Department 3016 Derby Hall/154 N. Oval Mall Ohio State University Columbus, OH 43210-1339 PH: (614) 292-6157 FAX: (614) 292-2055 Internet: Acker.1@osu.edu From rem-conf-request@es.net Thu Jun 30 12:15:29 1994 Received: from wawa.ans.net by osi-west.es.net via ESnet SMTP service id <03522-0@osi-west.es.net>; Thu, 30 Jun 1994 09:14:55 +0000 Received: by wawa.ans.net (AIX 3.2/UCB 5.64/4.03) id AA12569; Thu, 30 Jun 1994 16:08:57 GMT From: curtis@wawa.ans.net (Curtis Villamizar) Message-Id: <9406301608.AA12569@wawa.ans.net> To: Scoop4@aol.com Cc: rem-conf@es.net, rsvp@isi.edu Subject: Re: IEEE802.1 Looking for Guidance In-Reply-To: (Your message of Thu, 30 Jun 94 10:39:31 EDT.) <9406301039.tn207341@aol.com> Date: Thu, 30 Jun 94 16:08:57 +0000 > To that end, WE ARE SOLICITATING MULTIMEDIA LAN REQUIREMENTS, from > groups and individuals who ought to have an opinion about such things. > A group of individuals stands by to translate these requirements into > LLC Requests and Primatives which then will drive the efforts within > this International StandardsBody. The lack of response from a group that is actively _doing_ wide area multimedia may be a reflection of the opinion that putting a resource reservation protocol in the 802 LLC is an extremely bad idea and so willingness to participate is limited. If solutions are implemented at a higher level (RSVP for example rides on top of an internetworking layer rather than on top of a link layer), it becomes much easier to implement multimedia applications and reservation which span multiple connection media types (asynchronous connections, leased lines, frame relay, ethernets, other LAN, ATM, etc). Perhaps you could present the rationalle for putting this at 802 LLC at the Toronto IETF meeting to the RSVP WG. If interested, speak to the chairpersons. Curtis From rem-conf-request@es.net Thu Jun 30 17:31:40 1994 Received: from wizard.gsfc.nasa.gov by osi-west.es.net via ESnet SMTP service id <05468-0@osi-west.es.net>; Thu, 30 Jun 1994 14:31:22 +0000 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA20356; Thu, 30 Jun 94 17:31:06 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9406302131.AA20356@wizard.gsfc.nasa.gov> Subject: Re: IEEE802.1 Looking for Guidance To: curtis@wawa.ans.net (Curtis Villamizar) Date: Thu, 30 Jun 1994 17:31:05 -0400 (EDT) Cc: Scoop4@aol.com, rem-conf@es.net, rsvp@ISI.EDU In-Reply-To: <9406301608.AA12569@wawa.ans.net> from "Curtis Villamizar" at Jun 30, 94 04:08:57 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: 2323 > > To that end, WE ARE SOLICITATING MULTIMEDIA LAN REQUIREMENTS, from > > groups and individuals who ought to have an opinion about such things. > > A group of individuals stands by to translate these requirements into > > LLC Requests and Primatives which then will drive the efforts within > > this International StandardsBody. > > The lack of response from a group that is actively _doing_ wide area > multimedia may be a reflection of the opinion that putting a resource > reservation protocol in the 802 LLC is an extremely bad idea and so > willingness to participate is limited. If solutions are implemented > at a higher level (RSVP for example rides on top of an internetworking > layer rather than on top of a link layer), it becomes much easier to > implement multimedia applications and reservation which span multiple > connection media types (asynchronous connections, leased lines, frame > relay, ethernets, other LAN, ATM, etc). > > Perhaps you could present the rationalle for putting this at 802 LLC > at the Toronto IETF meeting to the RSVP WG. If interested, speak to > the chairpersons. > > Curtis I actually see this as something potentially very useful although I admit I don't know of any practical way to accomplish it. I know from personal experience that attempting to use the MBone conferencing tools over an intermediate congested Ethernet segment made them basically unusable (they have been very useful over moderately loaded networks). I think it is a very hard problem and one I haven't seen addressed much, as to what mechanisms are possible for making resource reservations over shared media such as Ethernet. And these mechanisms pretty much have to be at the data link layer since we live in a multiprotocol environment where IP isn't the only player in town. The only way I've been able to think about dealing with this particular problem is to basically bypass it by going to things like switched Ethernets where each workstation basically has a dedicated Ethernet, so it doesn't have to worry about contention on its local wire, and the Ethernet switch could implement resource reservation mechanisms (like dropping the normal best effort delivery packets to insure it could meet the delivery requirements of those packets having special QOS/bandwidth needs). -Bill From rem-conf-request@es.net Thu Jun 30 20:18:04 1994 Received: from MERCURY.LCS.MIT.EDU by osi-west.es.net via ESnet SMTP service id <06494-0@osi-west.es.net>; Thu, 30 Jun 1994 17:17:42 +0000 Received: (from jtw@localhost) by mercury.lcs.mit.edu (8.6.8.1/8.6.6) id UAA20169; Thu, 30 Jun 1994 20:07:59 -0400 Date: Thu, 30 Jun 1994 20:07:59 -0400 Message-Id: <199407010007.UAA20169@mercury.lcs.mit.edu> From: John Wroclawski To: curtis@wawa.ans.net CC: Scoop4@aol.com, rem-conf@es.net, rsvp@ISI.EDU In-reply-to: <9406301608.AA12569@wawa.ans.net> (curtis@wawa.ans.net) Subject: Re: IEEE802.1 Looking for Guidance From: curtis@wawa.ans.net (Curtis Villamizar) > To that end, WE ARE SOLICITATING MULTIMEDIA LAN REQUIREMENTS, from > groups and individuals who ought to have an opinion about such things. > A group of individuals stands by to translate these requirements into > LLC Requests and Primatives which then will drive the efforts within > this International StandardsBody. The lack of response from a group that is actively _doing_ wide area multimedia may be a reflection of the opinion that putting a resource reservation protocol in the 802 LLC is an extremely bad idea and so willingness to participate is limited. If solutions are implemented at a higher level (RSVP for example rides on top of an internetworking layer rather than on top of a link layer), it becomes much easier to implement multimedia applications and reservation which span multiple connection media types (asynchronous connections, leased lines, frame relay, ethernets, other LAN, ATM, etc). Curtis, I think these folks have an important piece of the puzzle on their table. I'm happy to egg them on in public... In fact, the chairs of the int_srv group did respond to their request for comments. We've received from them in return a clear expression of interest in cooperation between the two groups, if that proves to be a good idea. I believe that it is. Internet-level resource management will certainly need to make use of capabilities offered at the network level. Network-level facilities may become substantially simpler if large-system problems, such as scaling and management across many administrative domains, are addressed at the internet level. At minimum, we ought to try and avoid putting needless obstacles in each other's path - but I suspect we can do better. There's a clear opportunity for a total larger than the sum of the parts. cheers, -john John Wroclawski jtw@lcs.mit.edu From rem-conf-request@es.net Thu Jun 30 21:03:56 1994 Received: from bunyip.cc.uq.oz.au by osi-west.es.net via ESnet SMTP service id <06630-0@osi-west.es.net>; Thu, 30 Jun 1994 18:03:29 +0000 Received: from trapdoor.dstc.edu.au by bunyip.cc.uq.oz.au with SMTP (PP); Fri, 1 Jul 1994 11:01:26 +1000 Received: from azure.dstc.edu.au by trapdoor.dstc.edu.au (5.65/DSTC-Server) id ; Fri, 1 Jul 1994 11:00:12 +1000 Message-Id: <11486.9407010100@azure.dstc.edu.au> To: bill@wizard.gsfc.nasa.gov (Bill Fink) Cc: curtis@wawa.ans.net (Curtis Villamizar), Scoop4@aol.com, rem-conf@es.net, rsvp@ISI.EDU, frank@dstc.edu.au Subject: Re: IEEE802.1 Looking for Guidance In-Reply-To: Your message of "Thu, 30 Jun 94 17:31:05 -0400." <9406302131.AA20356@wizard.gsfc.nasa.gov> Date: Fri, 01 Jul 94 11:00:35 +1000 From: frank@dstc.edu.au X-Mts: smtp Your message dated: Thu, 30 Jun 94 17:31:05 -0400 ... > >I actually see this as something potentially very useful although I >admit I don't know of any practical way to accomplish it. I know from >personal experience that attempting to use the MBone conferencing tools >over an intermediate congested Ethernet segment made them basically >unusable (they have been very useful over moderately loaded networks). >I think it is a very hard problem and one I haven't seen addressed much, >as to what mechanisms are possible for making resource reservations over >shared media such as Ethernet. And these mechanisms pretty much have to >be at the data link layer since we live in a multiprotocol environment >where IP isn't the only player in town. > >The only way I've been able to think about dealing with this particular >problem is to basically bypass it by going to things like switched >Ethernets where each workstation basically has a dedicated Ethernet, >so it doesn't have to worry about contention on its local wire, and >the Ethernet switch could implement resource reservation mechanisms >(like dropping the normal best effort delivery packets to insure it >could meet the delivery requirements of those packets having special >QOS/bandwidth needs). > > -Bill Bill, This particular problem was the basis of my MEngSc degree: characterizing and improving the performance of AV communications over Ethernet LANs. The results of my work are contained in a thesis ("The monster is dead!" :) ), and two papers: F.R. Edwards and M.F. Schultz "Performance of VBR video communications on an Ethernet LAN: A trace-driven simulation study" Proc. 13th IEEE Int. Phoenix Conf. on Computers and Communications Phoenix, Arizona USA April 12-15 1994. F.R. Edwards and M.F. Schultz "A priority media access control protocol for video communication support on CSMA/CD LANs" To appear in ACM Multimedia Systems Basically, the first paper examines the performance problems associated with transmitting AV streams over Ethernet LANs and the effects of bursty data traffic on delay performance. The second paper proposes a solution through the use of a reservation-oriented, CSMA/CD-compatible priority MAC protocol. If anyone is interested in these papers, please e-mail and I'll see what I can do about FTP access. Hope this helps. OK. 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 -----