From rem-conf-request@es.net Sat Feb 01 02:11:51 1997 Received: from stilton.cisco.com by osi-west.es.net with ESnet SMTP (PP); Fri, 31 Jan 1997 23:11:09 -0800 Received: (dino@localhost) by stilton.cisco.com (8.6.12/8.6.5) id XAA28679; Fri, 31 Jan 1997 23:11:07 -0800 Date: Fri, 31 Jan 1997 23:11:07 -0800 Message-Id: <199702010711.XAA28679@stilton.cisco.com> From: Dino Farinacci To: mleelani@cisco.com CC: casner@precept.com, mleelani@cisco.com, rem-conf@es.net In-reply-to: <199702010327.TAA03048@chow.cisco.com> (message from Manoj Leelanivas on Fri, 31 Jan 1997 19:27:30 +73600 (PST)) Subject: Re: Minutes for AVT WG at San Jose IETF >> Yes, it has to keep a small source cache(S, G and the rate) to >> implement the way the protocol specifies it. Still the baggage is much >> lesser than the (S, G) entry which needs to keep track of the outgoing >> interfaces and such. Just to be clear, that is one way to implement it. We (cisco) did not implement it this way. Dino From rem-conf-request@es.net Sat Feb 01 02:12:44 1997 Received: from stilton.cisco.com by osi-west.es.net with ESnet SMTP (PP); Fri, 31 Jan 1997 23:11:51 -0800 Received: (dino@localhost) by stilton.cisco.com (8.6.12/8.6.5) id XAA28692; Fri, 31 Jan 1997 23:11:50 -0800 Date: Fri, 31 Jan 1997 23:11:50 -0800 Message-Id: <199702010711.XAA28692@stilton.cisco.com> From: Dino Farinacci To: casner@precept.com CC: mleelani@cisco.com, rem-conf@es.net In-reply-to: (message from Stephen Casner on Fri, 31 Jan 1997 19:48:16 -0800 ()) Subject: Re: Minutes for AVT WG at San Jose IETF >> And, it's important to make the distinction that it is only the leaf >> router which keeps this cache, and only for the sources sending >> through that leaf router. This compares to (S,G) routing state that >> would have to be kept in all the routers involved in the source-rooted >> trees, some of which would have to have state for all 20000 sources. And the RP for the same reasons. Dino From rem-conf-request@es.net Sat Feb 01 11:48:16 1997 Received: from emout06.mail.aol.com (actually emout06.mx.aol.com) by osi-west.es.net with ESnet SMTP (PP); Sat, 1 Feb 1997 08:47:27 -0800 Received: (from root@localhost) by emout06.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0) id LAA04922 for rem-conf@es.net; Sat, 1 Feb 1997 11:47:43 -0500 (EST) Date: Sat, 1 Feb 1997 11:47:43 -0500 (EST) From: Videoduck1@aol.com Message-ID: <970201114740_-1677634221@emout06.mail.aol.com> To: rem-conf@es.net Subject: UK ISDN Videoconferencing Demonstration Service Useful UK ISDN Videoconferencing Test/Demo Numbers and information can be found at: http://members.aol.com/videoduck1/ Hope it's useful. From rem-conf-request@es.net Sat Feb 01 11:55:11 1997 Received: from grunt.dejanews.com by osi-west.es.net with ESnet SMTP (PP); Sat, 1 Feb 1997 08:53:57 -0800 Received: (from dopost@localhost) by grunt.dejanews.com (8.7.6/8.7.3) id KAA16834; Sat, 1 Feb 1997 10:53:49 -0600 Path: grunt.dejanews.com!not-for-mail Date: Sat, 01 Feb 1997 10:53:49 -0600 From: Videoduck1@aol.com Subject: UK Videoconferencing Demo Numbers Newsgroups: comp.dcom.videoconf Message-Id: <854813944.15902@dejanews.com> Organization: Deja News Usenet Posting Service To: rem-conf@es.net X-Article-Creation-Date: Sat Feb 01 16:22:41 1997 GMT X-Originating-IP-Addr: 152.170.40.157 (170-40-157.ipt.aol.com) X-Http-User-Agent: Mozilla/2.0 (compatible; MSIE 3.0b; Windows 3.1) X-Authenticated-Sender: Videoduck1@aol.com [This is a courtesy copy of an article posted to Usenet via Deja News] For info check out the UK ISDN Videoconferencing Demonstration Service Website at: http://members.aol.com/videoduck1 -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet From rem-conf-request@es.net Sun Feb 02 05:24:16 1997 Received: from pccms.pku.edu.cn (actually 162.105.129.25) by osi-west.es.net with ESnet SMTP (PP); Sun, 2 Feb 1997 02:23:08 -0800 Received: by pccms.pku.edu.cn id AA05089 (5.67b8/IDA-1.5 for rem-conf@es.net); Sun, 2 Feb 1997 18:10:29 -0800 Message-Id: <199702030210.AA05089@pccms.pku.edu.cn> From: wangg@pccms.pku.edu.cn (Wang Gang) X-Mailer: SCO System V Mail (version 3.2) To: rem-conf@es.net Subject: subscribe Date: Sun, 2 Feb 97 18:10:29 bjt subscribe From rem-conf-request@es.net Sun Feb 02 09:46:59 1997 Received: from nemo.mth.msu.edu by osi-west.es.net with ESnet SMTP (PP); Sun, 2 Feb 1997 06:46:11 -0800 Received: by nemo.mth.msu.edu (SMI-8.6/SMI-SVR4) id JAA08937; Sun, 2 Feb 1997 09:46:07 -0500 Date: Sun, 2 Feb 1997 09:46:07 -0500 From: jyang@math.msu.edu (Jie Yang) Message-Id: <199702021446.JAA08937@nemo.mth.msu.edu> To: rem-conf@es.net Subject: unsubscribe unsubscribe From rem-conf-request@es.net Sun Feb 02 11:01:57 1997 Received: from emout19.mail.aol.com (actually emout19.mx.aol.com) by osi-west.es.net with ESnet SMTP (PP); Sun, 2 Feb 1997 08:01:20 -0800 Received: (from root@localhost) by emout19.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0) id LAA17667 for rem-conf@es.net; Sun, 2 Feb 1997 11:01:43 -0500 (EST) Date: Sun, 2 Feb 1997 11:01:43 -0500 (EST) From: VMatthies@aol.com Message-ID: <970202110143_1626257512@emout19.mail.aol.com> To: rem-conf@es.net Subject: unsubscribe unsubscribe From rem-conf-request@es.net Mon Feb 03 01:49:42 1997 Received: from chow.cisco.com by osi-west.es.net with ESnet SMTP (PP); Sun, 2 Feb 1997 22:48:58 -0800 Received: (mleelani@localhost) by chow.cisco.com (8.6.12/8.6.5) id WAA29947; Sun, 2 Feb 1997 22:48:56 -0800 From: Manoj Leelanivas Message-Id: <199702030648.WAA29947@chow.cisco.com> Subject: Re: Minutes for AVT WG at San Jose IETF To: casner@precept.com (Stephen Casner) Date: Sun, 2 Feb 1997 22:48:56 -0800 (PST) Cc: mleelani@cisco.com, rem-conf@es.net In-Reply-To: from "Stephen Casner" at Jan 31, 97 07:48:16 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1390 => => > Yes, it has to keep a small source cache(S, G and the rate) to => > implement the way the protocol specifies it. Still the baggage is much => > lesser than the (S, G) entry which needs to keep track of the outgoing => > interfaces and such. => => And, it's important to make the distinction that it is only the leaf => router which keeps this cache, and only for the sources sending => through that leaf router. This compares to (S,G) routing state that => would have to be kept in all the routers involved in the source-rooted => trees, some of which would have to have state for all 20000 sources. => Yes, and also at the RP as Dino mentioned earlier. => > The RP which is switching RTP traffic also may have sources which are => > sending RTP streams interrmittently. Even otherwise, it has to switch => > the traffic for the active source(ie, it is indeed loaded to an extent though => > switching path may be much faster). => => But doesn't that load get moved off to a source-rooted tree? => Since one of the receivers may have a higher threshold, the RP may be still forwarding packets through the shared tree. Or there could be a second lower rate source, which could contribute to the load at the RP. But, as you observed there is no concrete justification yet for separate groups instead of 1. -Manoj From rem-conf-request@es.net Mon Feb 03 11:22:00 1997 Received: from stilton.cisco.com by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Feb 1997 08:21:08 -0800 Received: (dino@localhost) by stilton.cisco.com (8.6.12/8.6.5) id IAA26646; Mon, 3 Feb 1997 08:21:06 -0800 Date: Mon, 3 Feb 1997 08:21:06 -0800 Message-Id: <199702031621.IAA26646@stilton.cisco.com> From: Dino Farinacci To: mleelani@cisco.com CC: casner@precept.com, mleelani@cisco.com, rem-conf@es.net In-reply-to: <199702030648.WAA29947@chow.cisco.com> (message from Manoj Leelanivas on Sun, 2 Feb 1997 22:48:56 -0800 (PST)) Subject: Re: Minutes for AVT WG at San Jose IETF >> Since one of the receivers may have a higher threshold, the RP may be >> still forwarding packets through the shared tree. Or there could be a >> second lower rate source, which could contribute to the load at the >> RP. But, as you observed there is no concrete justification yet for >> separate groups instead of 1. Or a branch of the source distribution tree flows through the RP. Dino From rem-conf-request@es.net Mon Feb 03 12:40:41 1997 Received: from mail-out2.apple.com by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Feb 1997 09:40:01 -0800 Received: from scv3.apple.com (A17-128-100-121.apple.com [17.128.100.121]) by mail-out2.apple.com (8.8.5/8.8.4) with ESMTP id JAA62644 for ; Mon, 3 Feb 1997 09:38:27 -0800 Received: from mailman.apple.com.CPT (mailman.apple.com [17.206.40.179]) by scv3.apple.com (8.8.5/8.8.4) with SMTP id JAA18488 for ; Mon, 3 Feb 1997 09:40:31 -0800 Received: from [17.255.9.131] (skylawn.research.apple.com) by mailman.apple.com.CPT (4.1/SMI-4.1) id AA07184; Mon, 3 Feb 97 09:35:57 PST Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 3 Feb 1997 09:39:59 -0800 To: rem-conf@es.net From: alagu@mailman.apple.com (Alagu Periyannan) Subject: Re: MBone teleconf tools for Macs? At 6:31 PM 1/30/97, Steve Deering wrote: > >> There is a tool called "Maven" available on the internet >> that will interoperate with VAT. > >Last I knew, Maven supported point-to-point (i.e., unicast) operation only. > Yes. You're probably right. I think it uses the old MacTCP API. If it is moved to use the OpenTransport API then multicast support can be added very easily. I think parts of Maven were incorporated into CUSeeMe. I'm not sure who maintains the standalone Maven nowadays. Anyone knows? Alagu Periyannan alagu@mailman.apple.com Communications Products and Technology Apple Computer, Inc. From rem-conf-request@es.net Mon Feb 03 14:07:30 1997 Received: from nobozo.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Feb 1997 11:06:44 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id LAA19628 for ; Mon, 3 Feb 1997 11:06:49 -0800 Date: Mon, 3 Feb 1997 11:06:49 -0800 Message-Id: <199702031906.LAA19628@nobozo.CS.Berkeley.EDU> X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: Jerrlyn Iwata Subject: [Reminder] Berkeley Multimedia & Graphics Seminar Berkeley Multimedia and Graphics Seminar (Wednesday February 5, 1997 12:30-2:00 PDT 405 Soda Hall) "The Impact of Future Developments in Flat Panel and Projection Display" Dave Mentley Stanford Resources, Inc. San Jose, CA ------------------------------------------------------------------------- This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40 PST (GMT - 8 hrs). See sdr or http://bmrc.berkeley.edu/298 for instructions on setting up, connecting to, and operating the MBONE tools. From rem-conf-request@es.net Mon Feb 03 14:11:11 1997 Received: from dan319.ece.ncsu.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Feb 1997 11:10:22 -0800 Received: (from klhewitt@localhost) by dan319.ece.ncsu.edu (8.8.4/EC19Dec96) id OAA00909 for rem-conf@es.net; Mon, 3 Feb 1997 14:10:19 -0500 (EST) From: Kathy Lynn Hewitt Message-Id: <9702031410.ZM907@eos.ncsu.edu> Date: Mon, 3 Feb 1997 14:10:18 -0500 X-Mailer: Z-Mail (3.2.1 10oct95) To: rem-conf@es.net Subject: wb crashes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi, I've got a new SUN Ultra running Solaris 2.5 to test out. I've been working with the mbone tools on it and am running into problems with the wb program. When wb is started from the command line or through sdr for any multicast session, it exits out and crashes with a segmentation fault when the "receive only" box is unchecked. You can view a session just fine, but you can't add to the whiteboard. I've seen this problem on another SUN machine we have running Solaris 2.4, but then again on my SUN (2.4), wb works just fine - no segmentation faults or anything. Also, on the "faulty" machines, I can start a unicast session and I don't run into any problems when I check the "receive only" button off. When I try running wbimport on one of the 2.4 machines, it appears to be locked up - none of the buttons work and you can't import anything. Then again, it works fine on a different 2.4 machine. Has anybody experienced this before or know of anything that I might try? Thanks for your help! --Kathy Hewitt -- ------------------------------------------------- Kathy Hewitt Dept. of Electrical and Computer Engineering North Carolina State University 919-515-5604 ------------------------------------------------- From rem-conf-request@es.net Tue Feb 04 14:32:12 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Feb 1997 11:31:08 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id LAA07640 for ; Tue, 4 Feb 1997 11:31:19 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma007618; Tue Feb 4 11:30:37 1997 Received: by hille.msri.org (8.7/MSRI) id LAA01121; Tue, 4 Feb 1997 11:29:36 -0800 (PST) Date: Tue, 4 Feb 1997 11:29:36 -0800 (PST) Message-Id: <199702041929.LAA01121@hille.msri.org> To: rem-conf@es.net From: mbone Reply-to: mbone@euclid.ucsd.edu Subject: Topics in Geometry and Physics MBone Broadcast Announcement ---------------------------- Title: Topics in Geometry and Physics Date: Feb 04, 1997 Time: 11:00 GMT 1 hours Contact: mbone@math.ucsd.edu URL: http://math.ucsd.edu/mbone/ Description: Prof. Raul Bott, "Lectures in De Rham Theory" mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Feb 04 14:33:10 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Feb 1997 11:32:13 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id LAA07725 for ; Tue, 4 Feb 1997 11:32:22 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma007689; Tue Feb 4 11:31:50 1997 Received: by hille.msri.org (8.7/MSRI) id LAA01151; Tue, 4 Feb 1997 11:30:50 -0800 (PST) Date: Tue, 4 Feb 1997 11:30:50 -0800 (PST) Message-Id: <199702041930.LAA01151@hille.msri.org> To: rem-conf@es.net From: mbone Reply-to: mbone@euclid.ucsd.edu Subject: Topics in Geometry and Physics MBone Broadcast Announcement ---------------------------- Title: Topics in Geometry and Physics Date: Feb 06, 1997 Time: 13:00 PST8PDT 1 hours Contact: mbone@math.ucsd.edu URL: http://math.ucsd.edu/mbone/ Description: Prof. Raul Bott, "Lectures in De Rham Theory" mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Feb 04 14:33:39 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Feb 1997 11:32:34 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id LAA07757 for ; Tue, 4 Feb 1997 11:32:37 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma007709; Tue Feb 4 11:32:16 1997 Received: by hille.msri.org (8.7/MSRI) id LAA01181; Tue, 4 Feb 1997 11:31:16 -0800 (PST) Date: Tue, 4 Feb 1997 11:31:16 -0800 (PST) Message-Id: <199702041931.LAA01181@hille.msri.org> To: rem-conf@es.net From: mbone Reply-to: mbone@euclid.ucsd.edu Subject: Topics in Geometry and Physics MBone Broadcast Announcement ---------------------------- Title: Topics in Geometry and Physics Date: Feb 07, 1997 Time: 11:00 PST8PDT 1 hours Contact: mbone@math.ucsd.edu URL: http://math.ucsd.edu/mbone/ Description: Prof. Raul Bott, "Lectures in De Rham Theory" mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Feb 04 14:34:14 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Feb 1997 11:33:28 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id LAA07826 for ; Tue, 4 Feb 1997 11:33:39 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma007787; Tue Feb 4 11:32:42 1997 Received: by hille.msri.org (8.7/MSRI) id LAA01211; Tue, 4 Feb 1997 11:31:41 -0800 (PST) Date: Tue, 4 Feb 1997 11:31:41 -0800 (PST) Message-Id: <199702041931.LAA01211@hille.msri.org> To: rem-conf@es.net From: mbone Reply-to: mbone@euclid.ucsd.edu Subject: Topics in Geometry and Physics MBone Broadcast Announcement ---------------------------- Title: Topics in Geometry and Physics Date: Feb 11, 1997 Time: 11:00 PST8PDT 1 hours Contact: mbone@math.ucsd.edu URL: http://math.ucsd.edu/mbone/ Description: Prof. Raul Bott, "Lectures in De Rham Theory" mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Feb 04 14:35:08 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Feb 1997 11:33:34 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id LAA07873 for ; Tue, 4 Feb 1997 11:33:44 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma007815; Tue Feb 4 11:33:24 1997 Received: by hille.msri.org (8.7/MSRI) id LAA01241; Tue, 4 Feb 1997 11:32:23 -0800 (PST) Date: Tue, 4 Feb 1997 11:32:23 -0800 (PST) Message-Id: <199702041932.LAA01241@hille.msri.org> To: rem-conf@es.net From: mbone Reply-to: mbone@euclid.ucsd.edu Subject: Topics in Geometry and Physics MBone Broadcast Announcement ---------------------------- Title: Topics in Geometry and Physics Date: Feb 13, 1997 Time: 13:00 PST8PDT 1 hours Contact: mbone@math.ucsd.edu URL: http://math.ucsd.edu/mbone/ Description: Prof. Raul Bott, "Lectures in De Rham Theory" mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Feb 04 14:36:36 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Feb 1997 11:35:38 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id LAA07957 for ; Tue, 4 Feb 1997 11:35:49 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma007940; Tue Feb 4 11:35:41 1997 Received: by hille.msri.org (8.7/MSRI) id LAA01271; Tue, 4 Feb 1997 11:34:41 -0800 (PST) Date: Tue, 4 Feb 1997 11:34:41 -0800 (PST) Message-Id: <199702041934.LAA01271@hille.msri.org> To: rem-conf@es.net From: mbone Reply-to: mbone@euclid.ucsd.edu Subject: UCSD, Mathematics - Lecture Series MBone Broadcast Announcement ---------------------------- Title: UCSD, Mathematics - Lecture Series Date: Feb 14, 1997 Time: 11:00 PST8PDT 1 hours Contact: mbone@math.ucsd.edu URL: http://math.ucsd.edu/mbone/ Description: Topicsin Geometry and Physics Prof. Raul Bott, "Lectures in De Rham Theory" mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Feb 04 14:40:06 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Feb 1997 11:38:39 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id LAA08082 for ; Tue, 4 Feb 1997 11:38:50 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma008050; Tue Feb 4 11:38:08 1997 Received: by hille.msri.org (8.7/MSRI) id LAA01301; Tue, 4 Feb 1997 11:37:08 -0800 (PST) Date: Tue, 4 Feb 1997 11:37:08 -0800 (PST) Message-Id: <199702041937.LAA01301@hille.msri.org> To: rem-conf@es.net From: mbone Reply-to: mbone@euclid.ucsd.edu Subject: UCSD, Mathematics - Lecture Series MBone Broadcast Announcement ---------------------------- Title: UCSD, Mathematics - Lecture Series Date: Feb 04, 1997 Time: 15:00 PST8PDT 2 hours Contact: mbone@math.ucsd.edu URL: http://math.ucsd.edu/mbone/ Description: Special Topics Prof. Harvey Friedman "The Formalization of Mathematics" Lecture notes for this presentation are available at http://math.ucsd.edu/mbone/freidman/talk1.html mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Feb 04 14:41:49 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Feb 1997 11:38:44 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id LAA08104 for ; Tue, 4 Feb 1997 11:38:55 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma008072; Tue Feb 4 11:38:44 1997 Received: by hille.msri.org (8.7/MSRI) id LAA01331; Tue, 4 Feb 1997 11:37:44 -0800 (PST) Date: Tue, 4 Feb 1997 11:37:44 -0800 (PST) Message-Id: <199702041937.LAA01331@hille.msri.org> To: rem-conf@es.net From: mbone Reply-to: mbone@euclid.ucsd.edu Subject: UCSD, Mathematics - Lecture Series MBone Broadcast Announcement ---------------------------- Title: UCSD, Mathematics - Lecture Series Date: Feb 05, 1997 Time: 11:00 PST8PDT 2 hours Contact: mbone@math.ucsd.edu URL: http://math.ucsd.edu/mbone/ Description: Special Topics Prof. Harvey Friedman "The Formalization of Mathematics" Lecture notes for this presentation are available at http://math.ucsd.edu/mbone/freidman/talk1.html mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Feb 04 15:03:33 1997 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Feb 1997 12:01:52 -0800 Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id MAA03599 for ; Tue, 4 Feb 1997 12:01:41 -0800 (PST) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.8.4/8.7.3) id MAA28237 for rem-conf@es.net; Tue, 4 Feb 1997 12:01:43 -0800 (PST) Original-Received: by ccm.hf.intel.com (ccmgate 3.2 #7) Tue, 04 Feb 97 12:01:42 PST PP-warning: Illegal Received field on preceding line Date: Tue, 04 Feb 97 09:23:00 PST From: John H Wilson Message-ID: To: rem-conf@es.net Subject: Encryption info in SDP draft-ietf-mmusic-sdp-02.txt defines a key field in a session announcement. For "public" announcements of conferences that require some form of registration, the field allows the specification of a URI at which to register. The "private" announcement that may be received as a result of this registration contains the key(s) that will be used on the RTP streams. However, I cannot find any definition of how the encryption algorithm(s) are specified. Clearly, it would be possible to define an application extension field to so specify, but do the authors have a better way? john_h_wilson@ccm.jf.intel.com From rem-conf-request@es.net Tue Feb 04 18:02:28 1997 Received: from buttle.lcs.mit.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Feb 1997 14:59:33 -0800 Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4) id RAA12399; Tue, 4 Feb 1997 17:51:44 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: John H Wilson cc: rem-conf@es.net Subject: Re: Encryption info in SDP In-reply-to: Your message of "Tue, 04 Feb 1997 09:23:00 PST." Date: Tue, 04 Feb 1997 17:51:44 -0500 Message-ID: <12397.855096704@buttle.lcs.mit.edu> Sender: mjh@buttle.lcs.mit.edu >draft-ietf-mmusic-sdp-02.txt defines a key field in a session >announcement. For "public" announcements of conferences that >require some form of registration, the field allows the >specification of a URI at which to register. The "private" >announcement that may be received as a result of this >registration contains the key(s) that will be used on the >RTP streams. > >However, I cannot find any definition of how the encryption >algorithm(s) are specified. Do you mean how the HTTP server specifies an encryption key in an HTTP reply? This should be specified, but I haven't given the issue any thought. It shouldn't be in the SDP spec though, because it is more general than just the context of SDP. My first thoughts are that a MIME content-type of application/key, with a payload as specified in the RTP a/V profile for user-entered pass phrases would be appropriate. Mark From rem-conf-request@es.net Wed Feb 05 13:57:28 1997 Received: from bugs-bunny.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Feb 1997 10:56:54 -0800 Received: from uclink4.berkeley.edu (uclink4.Berkeley.EDU [128.32.155.12]) by bugs-bunny.CS.Berkeley.EDU (8.8.4/8.8.2) with ESMTP id KAA16724 for <298-list@bmrc.berkeley.edu>; Wed, 5 Feb 1997 10:41:22 -0800 (PST) Received: from uclink2.berkeley.edu (uclink2.berkeley.edu [128.32.136.72]) by uclink4.berkeley.edu (8.8.4/8.6.12) with ESMTP id KAA23569; Wed, 5 Feb 1997 10:41:20 -0800 (PST) Received: from iastemp22 (iastemp22.IAS.Berkeley.EDU [128.32.226.78]) by uclink2.berkeley.edu (8.8.4/8.6.12) with SMTP id KAA01033; Wed, 5 Feb 1997 10:36:08 -0800 Message-Id: <3.0.32.19970205103801.009d6780@uclink2.Berkeley.edu> X-Sender: dianeh@uclink2.Berkeley.edu X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 05 Feb 1997 10:38:09 -0800 To: TOWNSEND@CMSA.BERKELEY.EDU, 298-list@bugs-bunny.CS.Berkeley.EDU, humcomp@info.sims.berkeley.edu From: Diane Harley Subject: From Wagner to Virtual Reality: A History of Multimedia/Randall Packer Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" A CyberSemester Lecture >From Wagner to Virtual Reality: A History of Multimedia Randall Packer, Visiting Lecturer, Art Practice Wednesday, February 5, 7:00-7:30PM 2050 Valley Life Sciences Building (http://socrates.berkeley.edu/~cybersem) ***************************************************** >From Wagner to Virtual Reality: A History of Multimedia, is a historical account of the avant-garde artists and scientists who have pushed the envelope of their respective disciplines to bring about the dissolution of boundaries that traditionally exist between the artistic and technological media. In the past twenty-five years, the intersection of art and human-computer interactivity has emerged as a mass medium, triggering new forms of artistic, entertainment, and educational content for laserdisc, CD-ROM, and the World Wide Web. This lecture follows the evolution of the various artistic and scientific disciplines that converge as multimedia, a critical overview of the past that provides a conceptual understanding of the digital medium, as well as a forum for informed discussion about the implications for the future. ***************************************************** Randall Packer is one of San Francisco's pioneering multimedia artists, composers and producers. Founder of Zakros InterArts / New Music Theatre in 1988, he has produced seminal interdisciplinary performance artworks, new music events, and lectures by such 20th century groundbreakers as John Cage, Karlheinz Stockhausen, Brian Eno, Laurie Anderson and Morton Subotnick. He has also created original works exploring new forms of interaction between live performance and the electronic media. Recently he completed two CD-ROMs of computer films and interactive media that were premiered this year at the San Francisco International Film Festival and the Mill Valley Film Festival. As an educator, Randall Packer was the first instructor and former director of San Francisco State University's acclaimed Multimedia Studies Program, one of the most comprehensive multimedia programs in the nation. For the past fifteen years, his work as an artist and historian has taken him around the world where he has held residencies at several institutes including Xerox PARC (Palo Alto Research Center), IRCAM (Institute for the Research and Coordination of Music) at the Centre Pompidou in Paris, and CCRMA (Center for the Coordination and Research in Music and Acoustics) at Stanford University. Packer lectures extensively on multimedia theory and aesthetics. He is currently a visiting lecturer at the University of California, Davis and the University of California, Berkeley, where he is teaching interdisciplinary art practices and the history of multimedia. ********************************************************* From rem-conf-request@es.net Wed Feb 05 14:36:16 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Feb 1997 11:35:22 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id LAA25341 for ; Wed, 5 Feb 1997 11:35:33 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma025321; Wed Feb 5 11:34:51 1997 Received: by hille.msri.org (8.7/MSRI) id LAA01784; Wed, 5 Feb 1997 11:33:52 -0800 (PST) Date: Wed, 5 Feb 1997 11:33:52 -0800 (PST) Message-Id: <199702051933.LAA01784@hille.msri.org> To: rem-conf@es.net From: mbone-support Reply-to: mbone-support@lists.stanford.edu Subject: The Stanford Channel MBone Broadcast Announcement ---------------------------- Title: The Stanford Channel Date: Feb 05, 1997 Time: 14:00 GMT 3 hours Contact: mbone-support@lists.stanford.edu URL: http://www-51.stanford.edu/ch51/home.html Description: In order to support multicast testing and to provide a consistent, high quality source of audio and video Stanford University will be transmitting the Stanford Channel over the mbone M-F 2-5pm PST. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Wed Feb 05 17:02:13 1997 Received: from burdell.cc.gatech.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Feb 1997 14:00:57 -0800 Received: from flora.cc.gatech.edu (kevin@flora.cc.gatech.edu [130.207.8.20]) by burdell.cc.gatech.edu (8.8.4/8.6.9) with ESMTP id RAA20546; Wed, 5 Feb 1997 17:00:52 -0500 (EST) Received: (from kevin@localhost) by flora.cc.gatech.edu (8.8.4/8.6.9) id RAA23761; Wed, 5 Feb 1997 17:00:51 -0500 (EST) Date: Wed, 5 Feb 1997 17:00:51 -0500 (EST) From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199702052200.RAA23761@flora.cc.gatech.edu> To: rem-conf@es.net Subject: MBone Community Size? Okay, I've asked this question before... how big is the MBone in terms of actual numbers of users? Well, here is my guess... At least since the beginning of 1995 I've been collecting statistics using Mlisten, a tool I wrote to capture the "control" packets sent by vic and vat. (See http://www.cc.gatech.edu/computing/Telecomm/mbone/ for more info) So I've been collecting this data on and off for about 2 years... sometimes for individual sessions, sometimes for all sessions, sometime just for audio, sometimes just for video. All told, I've got several 100s of Megabytes of data. I've taken this data, processed it, sorted it, uniqued it, etc. and came up with a list of 10,600 IP addresses. So over the past couple of years I've received at least one packet, via the MBone, from about this many IP addresses. Now there are obvious limitations to this sort of estimate, but it is the best I've seen. FYI. Any comments? -Kevin Almeroth From rem-conf-request@es.net Wed Feb 05 18:54:10 1997 Received: from george.lbl.gov by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Feb 1997 15:53:15 -0800 Received: (deba@localhost) by george.lbl.gov (8.6.10/8.6.5) id PAA03720; Wed, 5 Feb 1997 15:51:20 -0800 From: Deb Agarwal Message-Id: <199702052351.PAA03720@george.lbl.gov> Subject: MBone session announcement To: rem-conf@es.net Date: Wed, 5 Feb 1997 15:51:19 -0800 (PST) Cc: tonner@csd.uwm.edu (Brian Tonner) Reply-To: DAAgarwal@lbl.gov X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1893 MBone Broadcast Announcement ---------------------------- Title: LabWeb - The Spectro-Microscopy Collaboratory Dates: beginning - Feb 05, 1997 ending - indefinite (can be negotiated) Contacts: tonner@csd.uwm.edu DAAgarwal@lbl.gov URL: http://www-itg.lbl.gov/BL7Collab.html Description: We have built a prototype collaboratory testbed with the University of Wisconsin-Milwaukee that is allowing remote operation of a sophisticated synchrotron-radiation beamline in the Advanced Light Source (ALS) of Lawrence Berkeley National Laboratory. The Advanced Light Source is one of the brightest source of soft X-ray beams in the world today. The Spectro-Microscopy Facility consists of experimental analytical instruments attached to the first undulator beamline of the ALS, Beamline 7.0. Because of the unique capabilities of these instruments the Spectro Microscopy project is a large collaboration involving many institutions. Telepresence is a significant component of the collaboratory environment. Telepresence includes remotely controllable robotic cameras, a video switcher, and a videoconferencing session to transmit the video feed from the cameras. We have three cameras located throughout the ALS beamline floor space. We will be transmitting vic using h.261 format and vat using PCM format. The transmission bandwidth will be kept at a low rate when not in use for remote experimentation. We will be using a ttl of 127 to transmit this session. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Deb Agarwal e-mail:DAAgarwal@lbl.gov MS50B-2239 phone :(510)486-7078 Lawrence Berkeley National Lab Berkeley, CA 94530 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf-request@es.net Wed Feb 05 18:57:39 1997 Received: from also.media.org by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Feb 1997 15:57:05 -0800 Received: (from carl@localhost) by also.media.org (8.8.5/8.8.4/961211bjb) id SAA22317; Wed, 5 Feb 1997 18:57:02 -0500 (EST) From: "Carl Malamud [IMS]" Message-Id: <199702052357.SAA22317@also.media.org> Subject: Re: MBone Community Size? To: kevin@cc.gatech.edu (Kevin C. Almeroth) Date: Wed, 5 Feb 1997 18:57:01 -0500 (EST) Cc: rem-conf@es.net In-Reply-To: <199702052200.RAA23761@flora.cc.gatech.edu> from "Kevin C. Almeroth" at Feb 5, 97 05:00:51 pm Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > I've taken this data, processed it, sorted it, uniqued it, etc. and came > up with a list of 10,600 IP addresses. So over the past couple of years > I've received at least one packet, via the MBone, from about this many > IP addresses. > That number seems about right. To give some perspective, our main machines at IMS saw 720,000 unique IP addresses during 1996. Our live broadcasts would get a typical audience of 25-100 people and I believe NASA peaks at ~1000. Our typical download audience for ftp'able files is something like 1000-2000 downloads per week for our more popular programs, with that rate sustained pretty well over the course of the year. The numbers I've seen for RealAudio/Xing/.... are peak server capacities of 10k-15k streams for the very largest sites. I don't believe any of them are close to that in terms of real audiences and my guess is that the largest sites are looking at audiences of 1,000-5,000 streams at peak periods. The discussion in the last week or so on the lists has been very interesting. On the one hand, the ISP's say they'll support this when the demand is ready. On the other hand, mbone developers tend to be clinging to the "this is an experiment which must be carefully controlled" theory of software deployment. I'm not sure I believe the mbone is really all that fragile and distributed control seems to have worked very well for things like the web, despite very real fears of backbone collapse. My biggest fear for the mbone is that we control it so carefully that the demand never happens, the ISP's never support it properly, and the whole thing turns into a technically-correct solution that is buried by sub-optimal unicast streaming solutions. Carl From rem-conf-request@es.net Wed Feb 05 21:15:03 1997 Received: from burdell.cc.gatech.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Feb 1997 18:14:20 -0800 Received: from morticia.cc.gatech.edu (kevin@morticia.cc.gatech.edu [130.207.8.11]) by burdell.cc.gatech.edu (8.8.4/8.6.9) with ESMTP id VAA14308; Wed, 5 Feb 1997 21:14:18 -0500 (EST) Received: (from kevin@localhost) by morticia.cc.gatech.edu (8.8.4/8.6.9) id VAA11721; Wed, 5 Feb 1997 21:14:17 -0500 (EST) Date: Wed, 5 Feb 1997 21:14:17 -0500 (EST) From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199702060214.VAA11721@morticia.cc.gatech.edu> To: carl@also.media.org Subject: Re: MBone Community Size? Cc: rem-conf@es.net >>> I've taken this data, processed it, sorted it, uniqued it, etc. and came >>> up with a list of 10,600 IP addresses. So over the past couple of years >>> I've received at least one packet, via the MBone, from about this many >>> IP addresses. >>That number seems about right. To give some perspective, our >>main machines at IMS saw 720,000 unique IP addresses during 1996. >>Our live broadcasts would get a typical audience of 25-100 people >>and I believe NASA peaks at ~1000. I think 1000 is a bit high. I've tried to do a pretty accurate max and the most I ever saw on one of the shuttle sessions was about 450 people. Keep in mind that not all the people in the vat window are actually group members. Some who leave and don't send the final vat-appl-layer "group leave" msg (or if it is lost) hang around in the session list for another 15 mins or so. Of course, I have also missed a few missions so I'm not saying you're wrong Also, the most I've every seen on the MBone (as a whole) at any one time was during the LA IETF last year when the shuttle was also going on and I think there was one other "interesting" session. At -Kevin Almeroth that time I recall seeing just more than 600 total people. From rem-conf-request@es.net Wed Feb 05 21:40:27 1997 Received: from cs.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Feb 1997 18:39:05 -0800 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id VAA10751; Wed, 5 Feb 1997 21:39:03 -0500 (EST) Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id VAA12242; Wed, 5 Feb 1997 21:39:02 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <32F94446.18A@cs.columbia.edu> Date: Wed, 05 Feb 1997 21:39:02 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: "Kevin C. Almeroth" CC: carl@also.media.org, rem-conf@es.net Subject: Re: MBone Community Size? References: <199702060214.VAA11721@morticia.cc.gatech.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I wonder how many of the 10,600 are "this looks cool, let's try this - this is not ready for prime time and there's nothing interesting on - let me go back to RealAudio or VRML or other neat toy". In other words, how many addresses can be considered "regulars", who actually use this on a more or less daily or at least regular basis? I have the suspicion that Mbone "churn" may be pretty high; the core user community may be closer to the 600 mentioned... Part of the problem may also be that some of tools are not quite as robust on the Wintel platform or not fully available on the second/third-most common platform (Win 3.1/Apple) as on Unix. -- Henning Schulzrinne email: schulzrinne@cs.columbia.edu Dept. of Computer Science phone: +1 212 939-7042 Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs From rem-conf-request@es.net Thu Feb 06 06:43:29 1997 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Feb 1997 03:42:15 -0800 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 6 Feb 1997 11:41:41 +0000 To: kevin@cc.gatech.edu (Kevin C. Almeroth) cc: rem-conf@es.net Subject: Re: MBone Community Size? In-reply-to: Your message of "Wed, 05 Feb 1997 17:00:51 EST." <199702052200.RAA23761@flora.cc.gatech.edu> Date: Thu, 06 Feb 1997 11:41:40 +0000 Message-ID: <4396.855229300@cs.ucl.ac.uk> From: Jon Crowcroft we had 900 people listening to globecom......admittedley a lot via a ntt server based vidceo distribution system but nevertheless on the internet.... on the mbone, a plot of mbone events against time: (i may not have logged ALL mbone announcements) - starting from aeround sep 93 - grepping out dates, and then plotting frequecny of announce by month....over the last 50 or so months: ftp://cs.ucl.ac.uk/darpa/mbone-event-grow.ps From rem-conf-request@es.net Thu Feb 06 08:31:01 1997 Received: from mailhub.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Feb 1997 05:30:25 -0800 Received: from tao.fokus.gmd.de (tao [192.35.149.93]) by mailhub.fokus.gmd.de (8.8.3/8.8.3) with ESMTP id OAA18306 for ; Thu, 6 Feb 1997 14:30:18 +0100 (MET) From: Christian Zahl Received: (cz@localhost) by tao.fokus.gmd.de (SMI-8.6/8.6.12) id OAA06017 for rem-conf@es.net; Thu, 6 Feb 1997 14:30:12 +0100 Date: Thu, 6 Feb 1997 14:30:12 +0100 Message-Id: <199702061330.OAA06017@tao.fokus.gmd.de > X-Mailer: exmh version 1.6.1 5/23/95 To: rem-conf@es.net Subject: Question on IP/UDP/RTP header compression ID Mime-Version: 1.0 Content-Type: text/plain If have a littel problem with the understanding of one section in the ID for IP/UDP/RTP header compression. On page 3, section 3.1, the "FULL_HEADER" packet size ist explained: ".. The 4 bit sequence numer defined in section 3.3 ... is carried in the data field ... as defined in section 5.3.2 ... of [3]" Im not familar with IPv6 [3], so I do not understand, where to put the sequence number to :-) Does this mean, that it will be appended to the data following the IP header? If so, have the header to be changed in any way ("no" in my understanding, because the receiver will remove it). Any comments are welcome, Chris From rem-conf-request@es.net Thu Feb 06 13:34:26 1997 Received: from soleil.uvsq.fr by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Feb 1997 10:33:29 -0800 Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id TAA00780 ; Thu, 6 Feb 1997 19:31:57 +0100 (MET) Received: from Niel.prism.uvsq.fr (niel.prism.uvsq.fr [193.51.25.169]) by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with SMTP id TAA01784 for ; Thu, 6 Feb 1997 19:02:04 +0100 (MET) Message-Id: <1.5.4.32.19970206175746.006a021c@guillotin.prism.uvsq.fr> X-Sender: iccc@guillotin.prism.uvsq.fr (Unverified) X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 06 Feb 1997 18:57:46 +0100 To: congres@prism.uvsq.fr From: ICCC'97 Subject: ICCC'97 Announcement and Call for Papers International Conference for Computer Communications - ICCC'97 THEME: "Keys to a mature information society" November 19-21, 1997 Cannes, France The 13th biennal international conference organized by the International Council for Computer Communications. AIMS The conference aims is to provide an integrated perspective and a timely spectrum of computer and communications technologies in the context of present and future applications. TOPICS NEW TECHNOLOGIES Internetworking, Mobile Communications, Personal Wireless Communications, High Performance Computing, ATM, Broadband Networks, Architecture and Protocols NEW APPLICATIONS Desktop Video Conferencing, Broadband Applications e.g. Telemedicine, Telecommuting, Distance learning, Video on Demand, Multimedia, Electronic Commerce NEW SERVICES Intelligent Networks, Network Management, Virtual networks TRENDS AND STRATEGIES Information Highway, Information Filtering, Data Warehouse/Data Mining Security/ Privacy/ Legal Issues, User Acceptance/Billing, Commercialising Information POLICY AND GOVERNMENTAL ISSUES Information & communications policy, Control/Censorship Of Information, Deregulation/Liberalisation, Security/Privacy/Legal Issues, Role Of Government TARGET PARTICIPANTS Academics, accountants, advisors, auditors, consultants, doctors, engineers, investors, lawyers, planners, managers, policy makers, practitioners, researchers, scientists and others interested in communications and computer networks. CONFERENCE FORMAT The conference will last three days, November 19-21, 1977. Tutorials will be offered on November 17-18. LOCATION Cannes, a major mediterranean city on the French Riviera. SPONSORS ICCC (International Council for Computer Communications) and IFIP-TC.6 (International Federation of Information Processing, Technical Committee on Data Communications) ORGANIZER Telecom Valley, with the support of CNET (Centre National d'Etudes des T=E9l=E9communications), EURECOM, INRIA (Institut National de Recherche en Informatique et Automatique) Organizing Committee A. Andr=E9 (TV) E. Bibal (TV) P Conruyt (FT-DGSA) C. Gueguen (EURECOM) C. Juncker (INRIA) F. Jutand (CNET) T. Laurent (TV) G. Leb=E8gue (TV) L. Pouzin (ICCC) CONFERENCE CHAIR Samir Tohm=E9 (F) ENST 46 rue Barrault, 75634 Paris Cedex 13, France PROGRAMME CHAIR Guy Pujolle (F) Lab. PRiSM, University of Versailles 45 avenue des Etats-Unis, 78 035 Versailles Cedex, France PROGRAMME COMMITTEE J. Arnbak, Delft Technical Univ. (NL) F. Bar, Stanford Univ. (USA) C. Blondia, University of Antwerp (B) P. Brown, France Telecom - CNET (F) K. Boyanov, CICT (BG) A. Casaca, INESC (P) O. Casals, Universitat Politecnica de Catalunya (SP) P. Chemouil, France Telecom - CNET (F) S. J. Chung, ETRI (KR) J-P. Coudreuse, Mitsubishi (F) W. Dabbous, INRIA (F) Dang. N'Guyen, ENSTB (F) S. Fdida, University Paris VI (F) L. Fratta, Politecnico di Milano (I) D. Gaiti, Technical University of Troyes (F) C. Galand, IBM (F) N.D. Georganas, University of Ottawa (CA) A. Gravey, France Telecom - CNET (F) G. Hebuterne, INT (F) T. Housley, Housley Computer Communications (AU) C. Huitema, Bellcore (USA) P. Humblet, EURECOM (F) P. Jackson, Qualcomm (USA) F. Kamoun, ENSI (TU) M. Kato, Xerox (J) J. Kella, NET (IL) D. Khakhar, Lunds Univ. (S) P. K=FChn, Stuttgart Univ. (D) R. Kung, France Telecom - CNET (F) J. Labetoulle, EURECOM (F) J-Y. Le Boudec, EPFL (SW) O. Martikainen, Telecom Finland (FI) N. Naffah, Sabre Group (F) H. Perros, NCSU, (USA) S. Ramani, National Center for Software Technology (IN) J. Roberts, France Telecom - CNET (F) P. Rolin, ENSTB (F) O. Spaniol, Aachen Technical Univ. (D) E. Stefferud, NMA, USA Y. Takahashi, Aist-Nara (J) L. Tarouco, Univ. Federale de Rio Grande del Sul (BR) F. Tobagi, Stanford University (USA) C. Wellekens, EURECOM (F) KEY DATES IN 1997 * April 1st, papers received * June 1st, papers accepted /rejected * Sep 1st, papers received in camera ready form * Nov 17-18, Tutorials * Nov 19-21, ICCC'97 SUBMISSION OF PAPERS Paper can be submitted by mail or email * by mail: submit five copies of a full paper by April 1st, 1997 to ICCC97 Conference Lab PRiSM - University of Versailles 45 av. des Etats-Unis 78035 Versailles Cedex - France fax +33 (0) 139 254 057 http://www.prism.uvsq.fr * by email: poscript version of the paper to be sent to:= ICCC97@prism.uvsq.fr Papers are invited on the conference theme and related topics. Authors must state that their paper have neither been published before nor currently being submitted elsewhere. Full papers should be no longer than 15 pages, including tables, diagrams and pictures. The font size must be 12 points or larger. The cover page must contain an abstract of about 150 words, name and affiliation of author(s) as well as the lead author's postal address, telephone number, fax number and e-mail. Papers will be evaluated on the basis of relevance, originality and clarity. To ensure acceptance of high quality papers, each paper will be double and blind refereed. Accepted papers will be included in the conference proceedings and will be distributed to the attendees at the conference. The language of the conference is English and papers must be in this= language. For more information, fill and return the following form: ICCC97 Conference 905, rue Albert Einstein BP 261 06 921 Sophia Antipolis Cedex France ---------------------------------------------------------------------------- -------------- ICCC'97 1st Name: ...........................Last Name:...................................... email:...................................................................... ......... Title:...................................................................... ......... Organization:............................................................... ......... Postal address:....................................................................= .. ............................................................................ .......... City:.......................................Postal code:.............................. Country:.................................................................... .......... Telephone:.................................................................. ........... Fax:........................................................................ ........... Topics I am interested in : ........................................................... O Topics I am interested in :........................................................... O I wish to attend the ICCC=9297 conference. O I wish to present a paper and will submit a paper by Apil 15, 1997.=20 Title of the paper : ................................................................... ............................................................................ ............ ............................................................................ ............ _____________________________________________________________________ _____________________________________________________________________ From rem-conf-request@es.net Thu Feb 06 14:36:37 1997 Received: from mailhub.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Feb 1997 11:35:23 -0800 Received: from tao.fokus.gmd.de (tao [192.35.149.93]) by mailhub.fokus.gmd.de (8.8.3/8.8.3) with ESMTP id UAA24395 for ; Thu, 6 Feb 1997 20:35:16 +0100 (MET) From: Christian Zahl Received: (cz@localhost) by tao.fokus.gmd.de (SMI-8.6/8.6.12) id UAA06419 for rem-conf@es.net; Thu, 6 Feb 1997 20:35:13 +0100 Date: Thu, 6 Feb 1997 20:35:13 +0100 Message-Id: <199702061935.UAA06419@tao.fokus.gmd.de > X-Mailer: exmh version 1.6.1 5/23/95 To: rem-conf@es.net Subject: Question on IP/UDP/RTP compression Mime-Version: 1.0 Content-Type: text/plain Another question: see the following scenario (for one session): o RTP packets were sent as COMPRESSED_RTP, so that a context for this session exists. o the saved delta fields have been changed from the initial values (e.g. IP ID delta = 5, bacause of loss) o one RTP packet was sent as FULL_HEADERS or COMPRESSED_UDP o the next packet should be send as COMPRESSED_RTP The question is if the values in the context should be reset to their initial values, or if the values remain unchanged? So if the delta of the IP ID is 1 for the next packet to be send, do we have to indicate the change (set the I bit and include the new delta) or not? I think it makes sense to reset the values in the context to their initial values. This seems to be a "clean" resynchronisation... Thanks, Chris From rem-conf-request@es.net Thu Feb 06 15:16:17 1997 Received: from mailhub.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Feb 1997 12:15:10 -0800 Received: from tao.fokus.gmd.de (tao [192.35.149.93]) by mailhub.fokus.gmd.de (8.8.3/8.8.3) with ESMTP id VAA24689 for ; Thu, 6 Feb 1997 21:15:07 +0100 (MET) From: Christian Zahl Received: (cz@localhost) by tao.fokus.gmd.de (SMI-8.6/8.6.12) id VAA06436 for rem-conf@es.net; Thu, 6 Feb 1997 21:15:03 +0100 Date: Thu, 6 Feb 1997 21:15:03 +0100 Message-Id: <199702062015.VAA06436@tao.fokus.gmd.de > X-Mailer: exmh version 1.6.1 5/23/95 To: rem-conf@es.net Subject: IP/UDP/RTP compression and RTP payload-type Mime-Version: 1.0 Content-Type: text/plain 1. PT changes compression We are currently developing a method for transfering multiple RTP streams over a low-bandwidth PPP connection. The implementaion consists of an RTP mixer on both ends of the PPP link, which adjust the payload-type field according to the bandwidth available. So it can happen very often, that the payload (and so the PT field also) changes to adjust to the current bandwidth available (will measured while having by PPP link). Our major concern are modem connections. The current ID for IP/UDP/RTP compression doesn't have any compression thechnique for changes of the PT field. This means, that every change in the coding will result in sending an uncompressed RTP header (i.e. >=12 bytes instead of 2+1). Because we have a mixer, we also can assume to have a list of several CSRC entries, resulting in a even larger packet! Well it seems to be a little difficult to get a bit to indicate any change in the PT field, but it would be very helpfull to it! Otherwise it can happen, that the occupied bandwidth will be greater when adjusting the payload, than if we don't do so! Not very helpfull. I think it makes more sense to shorten the session context id to 7 bit and to add a P bit, which indicates a new octet with the changed PT value. 2. CSRC change compression Well as described above we use a mixer and expect several sources for the outgoing media stream. The current ID says, that, when the CSRC list changes, then the whole list has to be transmitted. Because there are several sources and we can assume that they also change more frequenctly, I think that sending the whole list ist very poor! I think if would be much better to send ONLY the CSRC entries which have been changed, i.e. added or removed. Because the other side also have knowledge of the current set of CSRC entries, it can decided if the entry as to be add or the be removed. This results in much less overhead than in the current ID. Only when the sum of the leaving and comming CSRC entries is larger than the current CSRC list, there will be send more than in the current ID. Any comments are welcome, Chris From rem-conf-request@es.net Thu Feb 06 16:57:52 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Feb 1997 13:56:35 -0800 Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id NAA02615; Thu, 6 Feb 1997 13:47:18 -0800 Date: Thu, 6 Feb 1997 13:49:26 -0800 () From: Stephen Casner To: Christian Zahl cc: rem-conf@es.net Subject: Re: several messages In-Reply-To: <199702061935.UAA06419@tao.fokus.gmd.de > Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Christian, Thanks for your comments on the IP/UDP/RTP header compression spec. > If have a littel problem with the understanding of one section in > the ID for IP/UDP/RTP header compression. On page 3, section > 3.1, the "FULL_HEADER" packet size ist explained: > ".. The 4 bit sequence numer defined in section 3.3 ... > is carried in the data field ... as defined in section > 5.3.2 ... of [3]" > > Im not familar with IPv6 [3], so I do not understand, where to put > the sequence number to :-) Does this mean, that it will be > appended to the data following the IP header? If so, have the header > to be changed in any way ("no" in my understanding, because the > receiver will remove it). I guess I need to make this more clear. Section 5.3.2 of [3] shows some diagrams indicating where the "Data" field is. This 8-bit field is a function recently added to the ipv6-hc compression draft as a "hook" for additional header compression schemes such as the RTP compression to pass data from the compressor to the decompressor. When using an 8-bit context ID, this field will be the low byte of the UDP length field of the FULL_HEADER packet. I should probably add the previous sentence to the draft. Perhaps this confusion about the specific Data field versus the general data part of the packet the follows the header stems from the difference in capitalization rules between English and German? :) > Another question: see the following scenario (for one session): > o RTP packets were sent as COMPRESSED_RTP, so that a context > for this session exists. > o the saved delta fields have been changed from the initial > values (e.g. IP ID delta = 5, bacause of loss) > o one RTP packet was sent as FULL_HEADERS or COMPRESSED_UDP > o the next packet should be send as COMPRESSED_RTP > > The question is if the values in the context should be reset to their > initial values, or if the values remain unchanged? So if the delta > of the IP ID is 1 for the next packet to be send, do we have to > indicate the change (set the I bit and include the new delta) or > not? The delta values MUST be reset by the FULL_HEADER packet since the first FULL_HEADER packet that the decompressor hears is what establishes the context. The purpose of the FULL_HEADER packet is to re-establish the context when the decompressor and the compressor get out of sync so you can't trust the any of the context values. Section 3.3 explains that the delta for the RTP timestamp field is reset whenever a FULL_HEADER, COMPRESSED_NON_TCP, or COMPRESSED_UDP packet is transmitted. However, I see that the rules for resetting the IP ID delta are not clear enough. The general idea is that when the absolute value of a field is transmitted, the delta is also reset. Therefore, the COMPRESSED_NON_TCP packet does reset the IP ID delta, but the COMPRESSED_UDP packet does not. In fact, the COMPRESSED_UDP packet makes use of the current value of the IP ID delta if the I bit is 0, or sets the value of the IP ID delta if the I bit is 1. I have a question about a possible misunderstanding that may be implied by your description of the scenario above. The loss which caused the IP ID to be set to 5 would have been upstream from the compressor; that is, it is not due to a loss between the compressor and decompressor. So, that by itself does not imply that a FULL_HEADER or COMPRESSED_UDP packet will be sent next. Therefore, did you mean that between the second and third bullets a packet was lost between the compressor and decompressor? -- Steve From rem-conf-request@es.net Fri Feb 07 05:14:53 1997 Received: from mailhub.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Feb 1997 02:14:07 -0800 Received: from tao.fokus.gmd.de (tao [192.35.149.93]) by mailhub.fokus.gmd.de (8.8.3/8.8.3) with ESMTP id LAA02840 for ; Fri, 7 Feb 1997 11:14:01 +0100 (MET) From: Christian Zahl Received: (cz@localhost) by tao.fokus.gmd.de (SMI-8.6/8.6.12) id LAA06707 for rem-conf@es.net; Fri, 7 Feb 1997 11:13:58 +0100 Date: Fri, 7 Feb 1997 11:13:58 +0100 Message-Id: <199702071013.LAA06707@tao.fokus.gmd.de > X-Mailer: exmh version 1.6.1 5/23/95 To: Stephen Casner Cc: rem-conf@es.net Subject: Re: several messages In-reply-to: Your message of "Thu, 06 Feb 1997 13:49:26 PST." Mime-Version: 1.0 Content-Type: text/plain Stephen, > I guess I need to make this more clear. Section 5.3.2 of [3] shows > some diagrams indicating where the "Data" field is. This 8-bit field > is a function recently added to the ipv6-hc compression draft as a > "hook" for additional header compression schemes such as the RTP > compression to pass data from the compressor to the decompressor. > When using an 8-bit context ID, this field will be the low byte of the > UDP length field of the FULL_HEADER packet. I should probably add the > previous sentence to the draft. Ok I see. BTW, a very stupid question: how about the high byte of the IPv4 header? Why isn't it used like the low byte for the context-id? > Perhaps this confusion about the specific Data field versus the > general data part of the packet the follows the header stems from the > difference in capitalization rules between English and German? :) Hm, perhaps; I don't see any difference between "Data field" and "data field" ?! Anyway, because I'm not familar with IPv6, I didn't know what the "Data field" is. > The delta values MUST be reset by the FULL_HEADER packet since the > first FULL_HEADER packet that the decompressor hears is what > establishes the context. The purpose of the FULL_HEADER packet is to > re-establish the context when the decompressor and the compressor get > out of sync so you can't trust the any of the context values. OK, that's what I've expected. > Section 3.3 explains that the delta for the RTP timestamp field is > reset whenever a FULL_HEADER, COMPRESSED_NON_TCP, or COMPRESSED_UDP > packet is transmitted. However, I see that the rules for resetting > the IP ID delta are not clear enough. The general idea is that when > the absolute value of a field is transmitted, the delta is also reset. > Therefore, the COMPRESSED_NON_TCP packet does reset the IP ID delta, > but the COMPRESSED_UDP packet does not. In fact, the COMPRESSED_UDP > packet makes use of the current value of the IP ID delta if the I bit > is 0, or sets the value of the IP ID delta if the I bit is 1. OK. > I have a question about a possible misunderstanding that may be > implied by your description of the scenario above. The loss which > caused the IP ID to be set to 5 would have been upstream from the > compressor; that is, it is not due to a loss between the compressor > and decompressor. So, that by itself does not imply that a > FULL_HEADER or COMPRESSED_UDP packet will be sent next. Therefore, That's right, so the scenareo wasn't the best one :-/ > did you mean that between the second and third bullets a packet was > lost between the compressor and decompressor? Either a loss of packets or any other change in the IP header (like the change of the TTL e.g.). But as you wrote in the ID, the IP ID field NORMALY increments by one, but it can also be used any other algorithm or by the upper layer (as defined in RFC791). So when the ID delta > 0x3fffff or <0, the FULL_HEADER packet HAVE to be transmitted. > -- Steve Thanks a lot for your statements, they helped me to understand some points much better and to validate my understanding. Bye, Chris P.S: any comments regarding my thought about PT and CSRC compression? From rem-conf-request@es.net Fri Feb 07 06:57:23 1997 Received: from soleil.uvsq.fr by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Feb 1997 03:56:30 -0800 Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id MAA21599 ; Fri, 7 Feb 1997 12:55:11 +0100 (MET) Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1]) by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id MAA12390 ; Fri, 7 Feb 1997 12:11:20 +0100 (MET) Received: from paranoia.u-net.net (mail.u-net.net [194.119.128.80]) by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id MAA19857 ; Fri, 7 Feb 1997 12:10:48 +0100 (MET) Received: from sgml.u-net.com ([193.119.188.188]) by mail.u-net.net with SMTP id <1310037-25883>; Fri, 7 Feb 1997 11:05:29 +0000 Message-Id: <1.5.4.32.19970207110717.006b7b04@mail.u-net.com> X-Sender: mtbryan-sgml@mail.u-net.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 07 Feb 1997 11:07:17 +0000 To: ICCC'97 , congres@prism.uvsq.fr From: Martin Bryan Subject: Re: ICCC'97 At 18:57 6/2/97 +0100, ICCC'97 wrote: >FYI. Last year we were still talking about the emerging IS. >Now we are talking about the mature IS. 1998 - postmortem >on the IS? Surely senile dementia sets in before the postmortem! ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ From rem-conf-request@es.net Fri Feb 07 07:05:30 1997 Received: from max3.rrze.uni-erlangen.de by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Feb 1997 04:04:52 -0800 Return-Path: Received: from urmel.rrze.uni-erlangen.de by max3.rrze.uni-erlangen.de; Fri, 7 Feb 97 13:04:05 +0100 Sender: unrzg5@rrze.uni-erlangen.de Message-ID: <32FB1A35.3E9@rrze.uni-erlangen.de> Date: Fri, 07 Feb 1997 13:04:05 +0100 From: Martin Fangmeyer Organization: University of Erlangen-Nuremberg X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5 sun4u) MIME-Version: 1.0 To: rem-conf@es.net Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe -- address Martin Fangmeyer/Werner-von-Siemens-Str. 12/Erlangen/Germany homepage http://www.rrze.uni-erlangen.de/~unrzg5 motorbike 1988-94 Suzuki GS 500 '80 oldie but goldie 1994-? Yamaha XJ900 '90 ... ten years after car Renault R4 can't beat _this_ feeling (now sold) From rem-conf-request@es.net Fri Feb 07 07:15:23 1997 Received: from mailhub.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Feb 1997 04:14:47 -0800 Received: from tao.fokus.gmd.de (tao [192.35.149.93]) by mailhub.fokus.gmd.de (8.8.3/8.8.3) with ESMTP id NAA05003 for ; Fri, 7 Feb 1997 13:07:13 +0100 (MET) From: Christian Zahl Received: (cz@localhost) by tao.fokus.gmd.de (SMI-8.6/8.6.12) id NAA06779 for rem-conf@es.net; Fri, 7 Feb 1997 13:07:10 +0100 Date: Fri, 7 Feb 1997 13:07:10 +0100 Message-Id: <199702071207.NAA06779@tao.fokus.gmd.de > X-Mailer: exmh version 1.6.1 5/23/95 To: Stephen Casner Cc: rem-conf@es.net Subject: Re: several messages (IP/UDP/RTP compr) In-reply-to: Your message of "Thu, 06 Feb 1997 13:49:26 PST." Mime-Version: 1.0 Content-Type: text/plain Stephen, > ... > but the COMPRESSED_UDP packet does not. In fact, the COMPRESSED_UDP > packet makes use of the current value of the IP ID delta if the I bit > is 0, or sets the value of the IP ID delta if the I bit is 1. > > I have a question about a possible misunderstanding that may be > implied by your description of the scenario above. The loss which > caused the IP ID to be set to 5 would have been upstream from the > compressor; that is, it is not due to a loss between the compressor > and decompressor. So, that by itself does not imply that a > FULL_HEADER or COMPRESSED_UDP packet will be sent next. Therefore, > did you mean that between the second and third bullets a packet was > lost between the compressor and decompressor? Here is another real example: Linux 2-x seems to generate the IP-ID a little bit different. The ID inclements by 1 but is send in little-endian encoding, so the following sequence of IP-IDs can occur without any loss of packages (I found this while looking into my PPP trace some minutes ago): IP-ID field fe 00 ff 00 00 01 - FULL_HEADER needed 01 01 You can see that in this case the FULL_HEADER type is needed, because the absolute value decreases when using the network-byte-order, without any kind of packet loss. Perhaps we should think about using negative values for the delta values? BTW, the same can theoretically happen when two IP packets arrive in the wrong order (packet N+1 first, then packet N). If this happens often, then the compression has NO gain! So how about of using INTs for the delta fields instead of UNSIGNEDs. Ok, this will reduce the maximum transferable delta value in one byte to +-63. If you think this is too less, then we can say: o the 1 byte form is UNSIGNED o the 2 and 3 byte forms are SIGNED What do you think about this idea? Thanks, Chris From rem-conf-request@es.net Fri Feb 07 08:57:00 1997 Received: from shiva.jussieu.fr by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Feb 1997 05:55:34 -0800 Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id OAA06932 ; Fri, 7 Feb 1997 14:50:44 +0100 (MET) Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1]) by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id OAA15471 ; Fri, 7 Feb 1997 14:31:48 +0100 (MET) Received: from callandor.cybercash.com (callandor.cybercash.com [204.178.186.70]) by soleil.uvsq.fr (8.8.5/jtpda-5.2) with SMTP id OAA24207 ; Fri, 7 Feb 1997 14:31:37 +0100 (MET) Received: by callandor.cybercash.com; id IAA10425; Fri, 7 Feb 1997 08:18:23 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma010418; Fri, 7 Feb 97 08:18:00 -0500 Received: by cybercash.com (4.1/SMI-4.1) id AA01622; Fri, 7 Feb 97 08:22:45 EST Date: Fri, 7 Feb 1997 08:22:44 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Martin Bryan , postmaster@prism.uvsq.fr, congres@prism.uvsq.fr Subject: PLEASE DELETE THIS MAILING LIST (Re: ICCC'97 (fwd)) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII It's bad enough that you were spamming everyone you could think of with the original message, which I got more than three copies of, now we has a damn coverstation being blasted out on a zillion mailing lists. Please stop this network abuse immeediately. Unsolicited mass email is not an appropriat way to advertise. Use web pages, appropriate news groups, and your own organizations mailing lists. Don't spam other mailing lists. Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html ---------- Forwarded message ---------- Date: Fri, 07 Feb 1997 11:07:17 +0000 From: Martin Bryan To: ICCC'97 , congres@prism.uvsq.fr Subject: Re: ICCC'97 At 18:57 6/2/97 +0100, ICCC'97 wrote: >FYI. Last year we were still talking about the emerging IS. >Now we are talking about the mature IS. 1998 - postmortem >on the IS? Surely senile dementia sets in before the postmortem! ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ From rem-conf-request@es.net Fri Feb 07 09:51:17 1997 Received: from cayman.ucs.indiana.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Feb 1997 06:50:28 -0800 Received: from stone51.netlab.indiana.edu (netlab-backup.netlab.indiana.edu [129.79.12.33]) by cayman.ucs.indiana.edu (8.7.3/8.7.3/1.12IUPO) with ESMTP id JAA31553 for ; Fri, 7 Feb 1997 09:50:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by stone51.netlab.indiana.edu (8.7.5/8.7.3) with ESMTP id JAA16570 for ; Fri, 7 Feb 1997 09:50:26 -0500 (EST) Message-Id: <199702071450.JAA16570@stone51.netlab.indiana.edu> X-Mailer: exmh version 2.0gamma 1/27/96 Reply-to: robelr@netlab.indiana.edu X-keywords: AllenRobel X-info: Allen Robel, 812-855-0962, 2711 E. 10th Street, Bloomington, IN 47408 To: rem-conf@es.net Subject: Cancellation: Cyberspace and the Future of Community Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Feb 1997 09:50:26 -0500 From: Allen Robel Hi, Due to insurmountable logistical problems, this event has been cancelled. Please accept our apologies. regards, -- Allen Robel Indiana University mailto:robelr@netlab.indiana.edu Area Code + Prefix: 812-855 http://www.netlab.indiana.edu/~robelr Office 0962, NetLab 3697, Fax 8299 From rem-conf-request@es.net Fri Feb 07 11:03:01 1997 Received: from ercole.cefriel.it by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Feb 1997 08:01:37 -0800 Received: from laguna (laguna [131.175.5.12]) by ercole.cefriel.it (8.7.5/8.7.3) with SMTP id QAA05477; Fri, 7 Feb 1997 16:55:25 +0100 (MET) Sender: campanal@mailer.cefriel.it Message-ID: <32FB5071.544F@mailer.cefriel.it> Date: Fri, 07 Feb 1997 16:55:29 +0100 From: Giuseppe Fabio Campanale Organization: CEFRIEL X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: Martin Fangmeyer CC: rem-conf@es.net Subject: Re: unsubscribe References: <32FB1A35.3E9@rrze.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Martin Fangmeyer wrote: > > unsubscribe > -- > address Martin Fangmeyer/Werner-von-Siemens-Str. 12/Erlangen/Germany > homepage http://www.rrze.uni-erlangen.de/~unrzg5 > motorbike 1988-94 Suzuki GS 500 '80 oldie but goldie > 1994-? Yamaha XJ900 '90 ... ten years after > car Renault R4 can't beat _this_ feeling (now sold) You should send your un-subscribe request to: rem-conf-request@es.net -- ++++++++++++++++++++++++++++++++++++++++++++++ Giuseppe Fabio Campanale c/o CEFRIEL - Politecnico di Milano Via L. Emanueli, 15 20126 MILANO - Italy mailto:campanal@mailer.cefriel.it fax : +39-2-66-100-448 URL : http://www.cefriel.it/ ++++++++++++++++++++++++++++++++++++++++++++++ From rem-conf-request@es.net Fri Feb 07 12:37:32 1997 Received: from coral.llnl.gov by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Feb 1997 09:36:32 -0800 Received: from [128.115.96.72] (jedsmac.llnl.gov [128.115.96.72]) by coral.llnl.gov (8.8.4/8.7.3/LLNL-Jun96) with ESMTP id JAA27455; Fri, 7 Feb 1997 09:36:24 -0800 (PST) Date: Fri, 7 Feb 1997 09:36:24 -0800 (PST) X-Sender: jed@coral.llnl.gov Message-Id: In-Reply-To: <199702052357.SAA22317@also.media.org> References: <199702052200.RAA23761@flora.cc.gatech.edu> from "Kevin C. Almeroth" at Feb 5, 97 05:00:51 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Carl Malamud [IMS]" From: "James E. [Jed] Donnelley" Subject: Re: MBone Community Size?, fragility of the MBone Cc: rem-conf@es.net, Petri Helenius >I'm not sure I believe the mbone is really all that fragile >and distributed control seems to have worked very well for >things like the web, despite very real fears of backbone collapse. >My biggest fear for the mbone is that we control it so carefully >that the demand never happens, the ISP's never support it >properly, and the whole thing turns into a technically-correct >solution that is buried by sub-optimal unicast streaming >solutions. I see more differences between the MBone and the Web that make the Web commercially viable and the MBone not (yet). Mainly with the Web there is much more tolerance for packet losses. This results from several factors: 1. TCP and the ability to wait (and wait and wait and ...) 2. If things are so bad that a connection times out on a Web transfer, what have I lost? Generally not much. No matter what it was, I can always try again (and do...). If I have been listening to a real time MBone multicast and it has my attention and then a crutial section is dropped, what have I lost? Potentially (and actually in my experience) a lot! Such lost sections can ruin an hours engagement. I got so frustrated with it that I stopped using it for serious interactions, and I am MUCH more tolerant of such things than most of my colleagues. I think the IP Multicast technology and the whole MBone approach as it stands have serious technical difficulties. You seem to belittle unicast streaming like "Real Audio", but from a user perspective it generally works. The bandwidth demand is low enough, it runs over TCP (takes care of packet losses) and you can even repeat it (not real time). I will mention for your possible interest a paper I wrote: http://www-atp.llnl.gov/atp/papers/HRM/HRM.html that develops what might be called TCP multicast. It is a different approach to reliable multicast than the "over IP multicast" crowd (e.g. RMP). It uses retransmission on a link by link basis (e.g. with TCP, but not necessarily) to achieve reliable end-to-end multicast. I think a technology like that with a fair amount of delay tolerance might make something like multicast "Real Audio" (even realtime) work. You would probably need a "catch up" technology (e.g. time compressed audio) for real time, but such an approach might give commercialization an opportunity. There is still the problem of allocating bandwidth. I don't really know why, but I don't see how the typical Internet laize faire "transmit when you can/dare" approach can work with real time multimedia. Perhaps it can. Maybe when the load gets too large the least interested people will begin to drop off and bring the load down. Something like that might work, but it doesn't seem likely to me. Perhaps it is just that I would be an early casualty, willing to pay the telephone charge for clarity. I think the simpliest test of this is "Internet Phone." As the bandwidth available on the Internet grows, why won't people just start doing more Internet telephoning to save long distance costs? Most noise tolerant first? I can't answer that one. Do you know Carl? Jed Donnelley jed@llnl.gov Phone: (510) 422-4309 http://www.webstart.com/jed/ FAX: (510) 423-1355 From rem-conf-request@es.net Fri Feb 07 13:12:58 1997 Received: from burdell.cc.gatech.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Feb 1997 10:11:32 -0800 Received: from morticia.cc.gatech.edu (kevin@morticia.cc.gatech.edu [130.207.8.11]) by burdell.cc.gatech.edu (8.8.4/8.6.9) with ESMTP id NAA10620; Fri, 7 Feb 1997 13:11:23 -0500 (EST) Received: (from kevin@localhost) by morticia.cc.gatech.edu (8.8.4/8.6.9) id NAA29392; Fri, 7 Feb 1997 13:11:18 -0500 (EST) Date: Fri, 7 Feb 1997 13:11:18 -0500 (EST) From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199702071811.NAA29392@morticia.cc.gatech.edu> To: schulzrinne@cs.columbia.edu Subject: Re: MBone Community Size? Cc: rem-conf@es.net >>I wonder how many of the 10,600 are "this looks cool, let's try this - >>this is not ready for prime time and there's nothing interesting on - >>let me go back to RealAudio or VRML or other neat toy". In other words, >>how many addresses can be considered "regulars", who actually use this >>on a more or less daily or at least regular basis? I have the suspicion >>that Mbone "churn" may be pretty high; the core user community may be >>closer to the 600 mentioned... Okay, I've thrown a few more statistics together and here's some additional info (I've also done a more careful search for IP addresses): 10,995 unique IP addresses 531,728 observed "connections" that I have data for (all over about a 2 year period) mean: 477 connections per IP address median: 261 connections per IP address max: 21,791 connections for one particular IP address (wow!) 25% of the IP addresses connected 126 times or less 50% of the IP addresses connected 261 times or less 75% of the IP addresses connected 473 times or less The least active 1% of IP addresses connected (on average) 6 times -Kevin From rem-conf-request@es.net Fri Feb 07 15:40:02 1997 Received: from mailhub.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Feb 1997 12:38:50 -0800 Received: from tao.fokus.gmd.de (tao [192.35.149.93]) by mailhub.fokus.gmd.de (8.8.3/8.8.3) with ESMTP id VAA12829 for ; Fri, 7 Feb 1997 21:38:44 +0100 (MET) From: Christian Zahl Received: (cz@localhost) by tao.fokus.gmd.de (SMI-8.6/8.6.12) id VAA07009 for rem-conf@es.net; Fri, 7 Feb 1997 21:38:40 +0100 Date: Fri, 7 Feb 1997 21:38:40 +0100 Message-Id: <199702072038.VAA07009@tao.fokus.gmd.de > X-Mailer: exmh version 1.6.1 5/23/95 To: rem-conf@es.net Cc: Stephen Casner Subject: Inconsistence in IP/UDP/RTP compression ID Mime-Version: 1.0 Content-Type: text/plain Well if I'm right then there seems to be a problem in the ID. I'm currently implementing a compessor according to the mentioned ID and have encountered a problem, if I'm right; any corrections are welcome :-) So imagine the following scenareo: o there are a RTP translator T, sitting on a host. o the translater passes the SSRC field of the incomming RTP streams unmodified (that's it's jobs, of course). o all IP packets are "owned" by the translator, i.e. the IP SRC and DST address are allways the same, also the UDP SRC and DST ports. o this results in a context for EACH sender the tranlater forwards, because of the different SSRC for each sender (which belongs to the session-context-indicator) Now think of two senders, which the translater receives and forwards. The IP/UDP pair will be generated out of from the translater, so they can be expected to be in sequence. We have two established contexts, one for sender A and one for sender B: +---+ IP(A,T) UDP(1,2) RTP(...,A,..) CXT cA | A | --------> +---+ +---+ | T | ------> IP(T,D) UDP(4,5) RTP(...,A|B,...) +---+ +---+ | B | ---------> +---+ IP(B,T) UDP(3,2) RTP(...,B,...) CXT cB Now sender A changes the payload-type. This forces the translator T to send the packet as COMPRESSED_UDP instead of COMPRESSED_RTP. There will arrive several questions: o to which context do the outgoing packet belongs, cA or cB? Do we have to create a new one? o will all other contexts belonging to this source (the tanslator) will be invalidated (cA and cB) ? On page 5 you can read: "COMPRESSED_UDP ... It redefines the SSRC field of the (potential) RTP header...". So the SSRC field has no meaning (in my understanding), because we cannot assume that we have an RTP packet. So we also cannot save any RTP header informations in the context (right?). Therefore, we have lost any kind of synchronization >from the compressor to the decompressor regarding this RTP stream! If so, this would result in sending a FULL_HEADER next, to resync. Or perhaps I have misunderstood one importand think: are contexts for the COMPRESSED_RTP and COMPRESSED_UDP are totally indepndent? >From one point of view this seems to make sense, but on the other side, it seems to be impossible to have two different applications using the same SRC and DST addresses and ports, so when we have an RTP context, the UDP context is a subset of it, isn't it? Stephen, perhaps you have an description what have to be sent in the scenareo shown above. I think in this point the ID is a little bit confusing :-) Well, I have to admit that I'm a little bit confused now :-/ So, any comments are welcome! Thanks, Chris From rem-conf-request@es.net Fri Feb 07 16:14:42 1997 Received: from bugs-bunny.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Feb 1997 13:13:44 -0800 Received: from nobozo.CS.Berkeley.EDU (nobozo.CS.Berkeley.EDU [128.32.34.58]) by bugs-bunny.CS.Berkeley.EDU (8.8.4/8.8.2) with SMTP id NAA08089 for <298-list@bmrc.berkeley.edu>; Fri, 7 Feb 1997 13:00:03 -0800 (PST) Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id NAA25572 for <298-list@bmrc.berkeley.edu>; Fri, 7 Feb 1997 13:00:01 -0800 Date: Fri, 7 Feb 1997 13:00:01 -0800 Message-Id: <199702072100.NAA25572@nobozo.CS.Berkeley.EDU> X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: 298-list@bugs-bunny.CS.Berkeley.EDU From: Jerrlyn Iwata Subject: Berkeley Multimedia & Graphics Seminar Berkeley Multimedia and Graphics Seminar (Wednesday February 5, 1997 12:30-2:00 PDT 405 Soda Hall) "The Impact of Future Developments in Flat Panel and Projection Display" Dave Mentley Stanford Resources, Inc. San Jose, CA The search for a useful and economical flat panel display began in the 1960s. The problem has been much harder to solve than anyone imagined, but the progress in recent years has also been astounding. Likewise, electronic projection technology, after many stagnant years, has accelerated to the point where a new generation of projector is arriving every year. Despite the progress, many issues remain to be resolved, particularly regarding performance, price and reliability. The talk will discuss the technology market and performance issues for LCDs, color plasma, projection displays and some of the advanced displays expected to make an impact within the next 5 years. Stanford Resources is interested in hiring folks to work on Electronic Display Market Research. Interested students should contact Dave Mentley. ------------------------------------------------------------------ This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40 PST (GMT - 8 hrs). See sdr or http://bmrc.berkeley.edu/298 for instructions on setting up, connecting to, and operating the MBONE tools. From rem-conf-request@es.net Fri Feb 07 16:17:20 1997 Received: from mailhub.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Feb 1997 13:15:43 -0800 Received: from tao.fokus.gmd.de (tao [192.35.149.93]) by mailhub.fokus.gmd.de (8.8.3/8.8.3) with ESMTP id WAA13050 for ; Fri, 7 Feb 1997 22:15:36 +0100 (MET) From: Christian Zahl Received: (cz@localhost) by tao.fokus.gmd.de (SMI-8.6/8.6.12) id WAA07035 for rem-conf@es.net; Fri, 7 Feb 1997 22:15:32 +0100 Date: Fri, 7 Feb 1997 22:15:32 +0100 Message-Id: <199702072115.WAA07035@tao.fokus.gmd.de > X-Mailer: exmh version 1.6.1 5/23/95 To: rem-conf@es.net Subject: Request for any comments: SDP compression Mime-Version: 1.0 Content-Type: text/plain During the last month I worked on the integration of low-bandwidth PPP users to the mbone. One of point of interest is the IP/UDP/RTP compression, for which Stephen Casner and Van Jacobson already set up an ID. Another issue of interest is the access to SDP session announcements. Currently, we have an (very alpha based) draft on how to compress SDP announcements. Another draft (currently in process) handles an efficient way to transfer informations of changes in the global SDP "cache". The current version of the SDP compression can be examined at: http://www.fokus.gmd.de/step/cz/da-cz/sdpCompr.html This doc also included some comparisons between gzip and the new compression technique. A draft for transfering SDP informations over an PPP link can be expected soon. Any comments are welcome, Chris From rem-conf-request@es.net Fri Feb 07 16:55:55 1997 Received: from bugs-bunny.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Feb 1997 13:54:37 -0800 Received: from nobozo.CS.Berkeley.EDU (nobozo.CS.Berkeley.EDU [128.32.34.58]) by bugs-bunny.CS.Berkeley.EDU (8.8.4/8.8.2) with SMTP id NAA08256 for <298-list@bmrc.berkeley.edu>; Fri, 7 Feb 1997 13:32:29 -0800 (PST) Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id NAA26317 for <298-list@bmrc.berkeley.edu>; Fri, 7 Feb 1997 13:32:29 -0800 Date: Fri, 7 Feb 1997 13:32:29 -0800 Message-Id: <199702072132.NAA26317@nobozo.CS.Berkeley.EDU> X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: 298-list@bugs-bunny.CS.Berkeley.EDU From: Jerrlyn Iwata Subject: [correction] Berkeley Multimedia & Graphics Seminar Berkeley Multimedia and Graphics Seminar (Wednesday February 12, 1997 12:30-2:00 PDT 405 Soda Hall) "Client-Server Architectures for PDA-based Applications" Wayne Citrin University of Colorado, Boulder Personal Digital Assistants [PDAs] are an attractive computational platform for mobile users, particularly due to their small size and weight and the ability to directly enter and interact with data on the display using a pen. However, the fact that PDAs are poor in computational resources generally precludes many useful applications. We have developed a client-server architecture that supports computationally intensive PDA-based applications by distributing functionality between a resource-poor PDA front end that gathers, displays, and stores data and performs basic recognition, and more computationally powerful host-based back ends that perform higher-level recognition tasks and database access. Communication between the front and back ends is over wired or wireless connections. We discuss the design of the architecture and its associated communications protocol, as well as related communications and performance issues. We also describe a prototype implementation based on the architecture that supports collaborative design and diagram recognition. This work was done in collaboration with Mark Gross of the College of Architecture and Design at the University of Colorado, and was supported in part by the Colorado Advanced Software Institute and US West Advanced Technologies. ------------------------------------------------------------------------------ This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40 PST (GMT - 8 hrs). See sdr or http://bmrc.berkeley.edu/298 for instructions on setting up, connecting to, and operating the MBONE tools. From rem-conf-request@es.net Fri Feb 07 18:30:11 1997 Received: from proxy3.ba.best.com by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Feb 1997 15:29:23 -0800 Received: from mg135-047.ricochet.net (mg135-047.ricochet.net [204.179.135.47]) by proxy3.ba.best.com (8.8.5/8.8.3) with SMTP id PAA20004; Fri, 7 Feb 1997 15:24:57 -0800 (PST) Date: Fri, 7 Feb 1997 15:24:57 -0800 (PST) Message-Id: <1.5.4.16.19970207161130.4f374efe@pop.best.com> X-Sender: rsf@pop.best.com X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "James E. [Jed] Donnelley" From: Ross Finlayson Subject: Re: MBone Community Size?, fragility of the MBone Cc: "Carl Malamud [IMS]" , rem-conf@es.net, Petri Helenius >I think the IP Multicast technology and the whole MBone >approach as it stands have serious technical difficulties. >You seem to belittle unicast streaming like "Real Audio", >but from a user perspective it generally works. The >bandwidth demand is low enough, it runs over TCP (takes >care of packet losses) and you can even repeat it >(not real time). Jed, I think you're being too pessimistic here. BTW, if you haven't already done so, you might want to try listening to the experimental 28.8 kbps MBone feed that the RealAudio folks set up recently. The quality is remarkable (& I think it actually uses something more like 20 kbps of bandwidth!). You can launch this from somewhere on RealAudio's web site, I think. (I also have it announced in multikit's "Public Grab Bag" directory, so if you're running multikit you can launch it from there.) Of course this is a live feed, so you don't get to repeat it. But I think there's some redundancy against packet loss built in. Now if only the RealAudio encoding were open (or alternatively, if only someone started demonstrating low-bandwidth feeds of similar quality using open standard encodings)... Ross. From rem-conf-request@es.net Fri Feb 07 18:36:08 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Feb 1997 15:35:09 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id PAA08253 for ; Fri, 7 Feb 1997 15:35:20 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma008230; Fri Feb 7 15:35:15 1997 Received: by hille.msri.org (8.7/MSRI) id PAA02850; Fri, 7 Feb 1997 15:34:18 -0800 (PST) Date: Fri, 7 Feb 1997 15:34:18 -0800 (PST) Message-Id: <199702072334.PAA02850@hille.msri.org> To: rem-conf@es.net From: lee Reply-to: lee@math.washington.edu Subject: Pacific Northwest Geometry Seminar MBone Broadcast Announcement ---------------------------- Title: Pacific Northwest Geometry Seminar Date: Feb 08, 1997 Time: 09:00 PST8PDT 9 hours Contact: lee@math.washington.edu URL: http://www.math.washington.edu/~lee/PNGS/97-winter/ Description: The talks by Marsden, Thurston, and Schoen will be broadcast live on the MBone (the Internet Multicast Backbone). They will also be rebroadcast on Tuesday, Wednesday, and Thursday, February 18-20, at noon PST. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Fri Feb 07 22:19:10 1997 Received: from george.lbl.gov by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Feb 1997 19:18:37 -0800 Received: (deba@localhost) by george.lbl.gov (8.6.10/8.6.5) id TAA14408 for rem-conf@es.net; Fri, 7 Feb 1997 19:16:23 -0800 From: Deb Agarwal Message-Id: <199702080316.TAA14408@george.lbl.gov> Subject: Length of sdr announcement warning To: rem-conf@es.net Date: Fri, 7 Feb 1997 19:16:23 -0800 (PST) Reply-To: DAAgarwal@lbl.gov X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 995 Hi all, I just ran up against a problem that many of you may not be aware of so I thought I'd write the list. My original sdr announcement of the LabWeb session was only going out to a small portion of the MBone. It turns out that I had placed so much descriptive text in the announcement that the multicast sdr packet containing the announcement was being fragmented. This caused it to be dropped by some routers in the MBone. Lesson learned! Don't make your session announcement overly verbose because that may keep it from going out. Deb Agarwal PS. There are no warnings in sdr or anywhere else telling you when an announcement is overly verbose. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Deb Agarwal e-mail:DAAgarwal@lbl.gov MS50B-2239 phone :(510)486-7078 Lawrence Berkeley National Lab Berkeley, CA 94720 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf-request@es.net Sat Feb 08 02:47:04 1997 Received: from silver.sms.fi by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Feb 1997 23:46:29 -0800 Received: (from pete@localhost) by silver.sms.fi (8.8.5/8.7.3) id JAA03407; Sat, 8 Feb 1997 09:46:23 +0200 (EET) Date: Sat, 8 Feb 1997 09:46:23 +0200 (EET) Message-Id: <199702080746.JAA03407@silver.sms.fi> From: Petri Helenius To: Ross Finlayson Cc: "James E. [Jed] Donnelley" , "Carl Malamud [IMS]" , rem-conf@es.net Subject: Re: MBone Community Size?, fragility of the MBone In-Reply-To: <1.5.4.16.19970207161130.4f374efe@pop.best.com> References: <1.5.4.16.19970207161130.4f374efe@pop.best.com> Ross Finlayson writes: > Now if only the RealAudio encoding were open (or alternatively, if only > someone started demonstrating low-bandwidth feeds of similar quality using > open standard encodings)... > Haven't unfortunately done that but there are two similar feeds running at addresses 224.42.42.2 and 224.42.42.4. First is at 112kbps and second at 24kbps. They are running using Xing technology MPEG audio encoders/decoders. Pick up the software from Xing or from http://www.ml.tele.fi and tune in! Pete From rem-conf-request@es.net Sat Feb 08 12:54:42 1997 Received: from buttle.lcs.mit.edu by osi-west.es.net with ESnet SMTP (PP); Sat, 8 Feb 1997 09:54:04 -0800 Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4) id MAA22130; Sat, 8 Feb 1997 12:52:52 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: DAAgarwal@lbl.gov cc: rem-conf@es.net Subject: Re: Length of sdr announcement warning In-reply-to: Your message of "Fri, 07 Feb 1997 19:16:23 PST." <199702080316.TAA14408@george.lbl.gov> Date: Sat, 08 Feb 1997 12:52:52 -0500 Message-ID: <22128.855424372@buttle.lcs.mit.edu> Sender: mjh@buttle.lcs.mit.edu >I just ran up against a problem that many of you may not >be aware of so I thought I'd write the list. My original >sdr announcement of the LabWeb session was only going out >to a small portion of the MBone. It turns out that I had >placed so much descriptive text in the announcement that >the multicast sdr packet containing the announcement was >being fragmented. This caused it to be dropped by some >routers in the MBone. > >Lesson learned! Don't make your session announcement overly >verbose because that may keep it from going out. Yes, that's what the URL is for. The GUI makes it difficult to add so much descriptive text that fragmentation is caused, but won't prohibit it. However sdr will reject announcements that are greater than 2K bytes (a somewhat arbitrary limit that we really never want to reach.) Point taken - a warning would be good. Mark From rem-conf-request@es.net Sat Feb 08 17:52:46 1997 Received: from burdell.cc.gatech.edu by osi-west.es.net with ESnet SMTP (PP); Sat, 8 Feb 1997 14:52:07 -0800 Received: from flora.cc.gatech.edu (root@flora.cc.gatech.edu [130.207.8.20]) by burdell.cc.gatech.edu (8.8.4/8.6.9) with ESMTP id RAA06030 for ; Sat, 8 Feb 1997 17:52:05 -0500 (EST) Received: (from kevin@localhost) by flora.cc.gatech.edu (8.8.4/8.6.9) id JAA03441 for rem-conf@es.net; Sat, 8 Feb 1997 09:28:38 -0500 (EST) Date: Sat, 8 Feb 1997 09:28:38 -0500 (EST) From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199702081428.JAA03441@flora.cc.gatech.edu> To: rem-conf@es.net Subject: Re: MBone Community Size?, fragility of the MBone >>I see more differences between the MBone and the Web that >>make the Web commercially viable and the MBone not (yet). The web is commercially viable today? I certainly disagree. Sure you can point to a few businesses but they are limping along. The web's commercial viability suffers from its own set of (security) problems. In your comparison, the web is not much better than the MBone. >>2. If things are so bad that a connection times out on >>a Web transfer, what have I lost? Generally not much. >>No matter what it was, I can always try again (and do...). >>If I have been listening to a real time MBone multicast >>and it has my attention and then a crutial section is >>dropped, what have I lost? Potentially (and actually in >>my experience) a lot! Such lost sections can ruin an >>hours engagement. I got so frustrated with it that I >>stopped using it for serious interactions, and I am >>MUCH more tolerant of such things than most of my >>colleagues. If you use the web and don't get what you want, you've lost whatever you were trying to get. I've stopped using some sites because I can't tolerate the extremely long wait times. There went their commercial viability. In your comparison, the web is not much better than the MBone. >>I think the IP Multicast technology and the whole MBone >>approach as it stands have serious technical difficulties. No doubt. So what do you suggest we do with the MBone? Throw it away and go to TCP multicast? You'll have a hard time getting a majority of people buy into the premise that the MBone has failed and then get those same people to believe a better way is to use TCP multicast. But that's just my opinion. The MBone is continually being improved and offers a somewhat orthogonal solution to reliable multicast. Applications exist which are better supported by one or the other. Independent of the problem of available bandwidth of course. -Kevin Almeroth From rem-conf-request@es.net Sun Feb 09 17:42:34 1997 Received: from tis-mail.thepoint.net (actually tis-backup.thepoint.net) by osi-west.es.net with ESnet SMTP (PP); Sun, 9 Feb 1997 14:35:29 -0800 Received: by tis-mail.thepoint.net with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC16AF.848EA500@tis-mail.thepoint.net>; Sun, 9 Feb 1997 17:34:35 -0500 Message-ID: From: Arlie Davis To: "'kevin@cc.gatech.edu'" Cc: "'rem-conf@es.net'" Subject: RE: MBone Community Size?, fragility of the MBone Date: Sun, 9 Feb 1997 17:34:34 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The web is commercially viable in some ways, if not all. One of the real selling points of the web is that it allows companies to provide a great deal of very detailed information to (potential and real) customers. The revenue gained from this is very real. True, not many people are successfully selling products on the web. At least the transaction is not occurring there; many people do a lot of feature-comparing and shopping on the web, then call to place the order, or other hybrids. This has almost nothing to do with why the MBONE is not commercially viable. It's a completely different set of problems. First and foremost, the major stumbling block for multicast applications (commercial and otherwise) is the lack of a fast, robust, well-administered multicast routing infrastructure. Many ISPs don't understand multicast; many think that it will increase their link utilization, when in all likelihood it will decrease it due to elimination of redundant feeds. Second, security for MBONE technologies is not much of a problem, or at least it is not a central requirement. The applications that need it support it, usually in the form of encryption. Also, I doubt that you'll ever have a multipoint financial transaction -- that's a unicast thing. -- arlie >-----Original Message----- >From: kevin@cc.gatech.edu [SMTP:kevin@cc.gatech.edu] >Sent: Saturday, February 08, 1997 9:29 AM >To: rem-conf@es.net >Subject: Re: MBone Community Size?, fragility of the MBone > >>>I see more differences between the MBone and the Web that >>>make the Web commercially viable and the MBone not (yet). > >The web is commercially viable today? I certainly disagree. >Sure you can point to a few businesses but they are limping >along. The web's commercial viability suffers from its own >set of (security) problems. > >In your comparison, the web is not much better than the MBone. From rem-conf-request@es.net Sun Feb 09 20:13:53 1997 Received: from broon.off.connect.com.au by osi-west.es.net with ESnet SMTP (PP); Sun, 9 Feb 1997 17:13:08 -0800 Received: from connect.com.au (ggm@localhost) by broon.off.connect.com.au with ESMTP id LAA09034 (8.8.5/IDA-1.6); Mon, 10 Feb 1997 11:11:34 +1000 (EST) X-Authentication-Warning: broon.off.connect.com.au: ggm owned process doing -bs X-Mailer: exmh version 1.6.9 8/22/96 To: Arlie Davis cc: "'kevin@cc.gatech.edu'" , "'rem-conf@es.net'" Subject: Re: MBone Community Size?, fragility of the MBone In-reply-to: Your message of "Sun, 09 Feb 1997 17:34:34 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Feb 1997 11:11:33 +1000 Message-ID: <9033.855537093@connect.com.au> From: George Michaelson I take a more cynical view Arlie. The reason MBONE is not commercially viable is that nobody has worked out how to make an awsome profit from it, and nobody at the PC/Mac cutting edge has put that into a free app people want to use over any other toy. Being commercially viable doesn't mean its well engineered or even works, and by jingo a LOT of internet productization right now is about selling snake oil in broken glass bottles. MBONE is hard financials. Its about making some amount of b/w available and selling it to people. If you understand MBONE then you probably understand that somebody else is also getting it, and paying for it too, and pretty soon recipients start asking how much of the shared cost they should be paying and what the profit-points are like. In other words the more you sell the better the margin, but the more you sell the bigger the pressure to sell it cheaper. The 'defensive' reasons we all cite for why MBONE is preferable to pt-to-pt multi-way are not sells. Nothing is being driven by ISP's being smart right now, its all about end-users being smarter and code-releasing people getting stuff into their hands. ISPs are the lag-point, not the innovators. Innovation comes from people like Van, who seems to have written vat for three or four core reasons: he wanted to his users wanted a tool like that his funding body wanted to save money on travel and vat helped I sure am glad he's not working in the ISP business. If he was he'd be stuck writing financials packages and re-working the billing system around a version of tcpdump from satan. MBONE is the same. Its not cisco's in-house killer protocol they went out and sold en-masse to the SNA users of the world (like GRE and STUN) its something nifty, but its not the bottom line. -George -- George Michaelson | connect.com.au pty/ltd Email: ggm@connect.com.au | c/o AAPT, Phone: +61 7 3834 9976 | level 8, the Riverside Centre, Fax: +61 7 3834 9908 | 123 Eagle St, Brisbane QLD 4000 From rem-conf-request@es.net Sun Feb 09 21:29:05 1997 Received: from also.media.org by osi-west.es.net with ESnet SMTP (PP); Sun, 9 Feb 1997 18:28:22 -0800 Received: (from carl@localhost) by also.media.org (8.8.5/8.8.4/961211bjb) id VAA03830; Sun, 9 Feb 1997 21:26:55 -0500 (EST) From: "Carl Malamud [IMS]" Message-Id: <199702100226.VAA03830@also.media.org> Subject: Re: MBone Community Size?, fragility of the MBone To: ggm@connect.com.au (George Michaelson) Date: Sun, 9 Feb 1997 21:26:55 -0500 (EST) Cc: arlie@thepoint.net, kevin@cc.gatech.edu, rem-conf@es.net In-Reply-To: <9033.855537093@connect.com.au> from "George Michaelson" at Feb 10, 97 11:11:33 am Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit According to George Michaelson: > > > I take a more cynical view Arlie. > > The reason MBONE is not commercially viable is that nobody has worked out > how to make an awsome profit from it, and nobody at the PC/Mac cutting > edge has put that into a free app people want to use over any other toy. > My view of the mbone was that is was simply one of many different ways to get our content out. For the National Press Club, for example, we would send the data live out via mbone, but also use multicast to record the data on disk, then turn it into various other "streaming" formats (e.g., .au, .gsm, .ra) and then serve that back out via a web interface. To me the mbone was a tool, not a product. Nobody is going to make a living out of "multicasting content" but they might be able to use multicasting as one of the (many) tools to package the content in an attractive way. From rem-conf-request@es.net Sun Feb 09 21:45:34 1997 Received: from broon.off.connect.com.au by osi-west.es.net with ESnet SMTP (PP); Sun, 9 Feb 1997 18:44:50 -0800 Received: from connect.com.au (ggm@localhost) by broon.off.connect.com.au with ESMTP id MAA10671 (8.8.5/IDA-1.6); Mon, 10 Feb 1997 12:42:56 +1000 (EST) X-Authentication-Warning: broon.off.connect.com.au: ggm owned process doing -bs To: "Carl Malamud [IMS]" cc: arlie@thepoint.net, kevin@cc.gatech.edu, rem-conf@es.net Subject: Re: MBone Community Size?, fragility of the MBone In-reply-to: Your message of "Sun, 09 Feb 1997 21:26:55 EST." <199702100226.VAA03830@also.media.org> Date: Mon, 10 Feb 1997 12:42:50 +1000 Message-ID: <10666.855542570@connect.com.au> From: George Michaelson My view of the mbone was that is was simply one of many different ways to get our content out. For the National Press Club, for example, we would send the data live out via mbone, but also use multicast to record the data on disk, then turn it into various other "streaming" formats (e.g., .au, .gsm, .ra) and then serve that back out via a web interface. This is a good view. Its a view that says delivery method is less exciting than the content. Its under-the-cover stuff. To me the mbone was a tool, not a product. Nobody is going to make a living out of "multicasting content" but they might be able to use multicasting as one of the (many) tools to package the content in an attractive way. I totally agree. Its like asking why home video editing suites can't do SMPTE timestamp based edit and don't come with jog-shuttle. Its not because they aren't useful tools, and if your 'market' is professional video editors you can expect these to be checkbox items. If your prime interest is getting the material into peoples hands, who cares anyway? I think mbone suffers from the confusion/blurred destinction of infrastructure and end-use. Carl, did you find mbone actually 'made a difference' there? Was the pain worth the benefits? did the final .ra and other forms sound acceptable even after filtering through MBONE as a delivery path? -George -- George Michaelson | connect.com.au pty/ltd Email: ggm@connect.com.au | c/o AAPT, Phone: +61 7 3834 9976 | level 8, the Riverside Centre, Fax: +61 7 3834 9908 | 123 Eagle St, Brisbane QLD 4000 From rem-conf-request@es.net Mon Feb 10 01:54:28 1997 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Sun, 9 Feb 1997 22:53:36 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 10 Feb 1997 06:51:17 +0000 To: George Michaelson cc: "Carl Malamud [IMS]" , arlie@thepoint.net, kevin@cc.gatech.edu, rem-conf@es.net Subject: Re: MBone Community Size?, fragility of the MBone In-reply-to: Your message of "Mon, 10 Feb 1997 12:42:50 +1000." <10666.855542570@connect.com.au> Date: Mon, 10 Feb 1997 06:51:13 +0000 Message-ID: <691.855557473@cs.ucl.ac.uk> From: Jon Crowcroft > To me the mbone was a tool, not a product. Nobody is going to make > a living out of "multicasting content" but they might be able > to use multicasting as one of the (many) tools to package the content > in an attractive way. according to a recent seminar here by mike lesk, very few people are making much money out of the web either, so this is a spurious distinction..... most commercial people (as per the doonesbury cartoon on the subject) are on the web because the hype has made them "scared they will look stupid if they are not". sure there are some positive cases, but selling information is not big business (except share prices and people just dont do that yet there) video/audio content IS big business, but has stringent quality expectations which the mbone cannot do... actually, the quality issue is the same for the web - as soon as the underlying net can deliver guaratees (e.g. ipsec, int-serv, type guarantees) then the share delaers might think about serious use of the public internet - just the same as the tv and radio people but for now, disney, reuters alike, just keep a watching brief jon From rem-conf-request@es.net Mon Feb 10 02:14:00 1997 Received: from broon.off.connect.com.au by osi-west.es.net with ESnet SMTP (PP); Sun, 9 Feb 1997 23:13:23 -0800 Received: from connect.com.au (ggm@localhost) by broon.off.connect.com.au with ESMTP id RAA15906 (8.8.5/IDA-1.6); Mon, 10 Feb 1997 17:11:07 +1000 (EST) X-Authentication-Warning: broon.off.connect.com.au: ggm owned process doing -bs To: Jon Crowcroft cc: "Carl Malamud [IMS]" , arlie@thepoint.net, kevin@cc.gatech.edu, rem-conf@es.net Subject: Re: MBone Community Size?, fragility of the MBone In-reply-to: Your message of "Mon, 10 Feb 1997 06:51:13 GMT." <691.855557473@cs.ucl.ac.uk> Date: Mon, 10 Feb 1997 17:11:06 +1000 Message-ID: <15904.855558666@connect.com.au> From: George Michaelson I think quite a lot of people are making money from the web. Little of it is justified and little of it looks to be good longterm business. I suspect that the ability of existing broadcast media to send one instance of VERY expensive production to around 200,000,000 people simultaneously changes the quality pressure somewhat. Even if only 1% dislike the soundmix you can expect a LOT of calls onto a helpdesk to complain (people who don't have hearing loss will wonder on that, but I know from my own experience with mild loss, and older peoples war-induced major loss, that soundmix is the number-1 complaint about TV shows after excessive (or insufficient) flesh content. Words and MUSAK do not mix.) Right now MBONE leverages off willingness of recipients (because when its being used many-to-many it still typically one speaker many listener modes for a variant set of speaker, listener pair/tuples) to put up with the quality, and it also leverages off the higher quality sourcing for some feeds. If it was all done using quickcam or ISA-bus video onto 8bit-cards it would be even more dire. I think the main uses of MBONE haven't even begun to be clear. When it looked like NNTP was going to be a winner under RMP I thought that was it because traffic efficient porn has to be a good choice, but it didn't work. Likewise when people doing layered codings I assumed we'd see multi-lingual soundflow over the slowscan image for IETF (surely with that many francophones on the councils they would push for this :-) but I don't hear much about that or title-options, or any of a number of things that digital TV is touted as providing. So is there some chance that Digital TV is also doomed to failure? Do people really not want the features? -George From rem-conf-request@es.net Mon Feb 10 05:16:11 1997 Received: from sumo.vocaltec.co.il by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Feb 1997 02:15:21 -0800 Received: from maskit1.vocaltec.co.il (patish.vocaltec.co.il [199.203.72.3]) by sumo.vocaltec.co.il (8.6.12/8.6.12) with SMTP id MAA08780; Mon, 10 Feb 1997 12:11:52 +0200 From: Scott_Petrack@vocaltec.com Received: by maskit1.vocaltec.co.il(Lotus SMTP MTA v1.05 (274.9 11-27-1996)) id 4225643A.00382CCA ; Mon, 10 Feb 1997 12:13:34 +0200 X-Lotus-FromDomain: VOCALTEC To: J.Crowcroft@cs.ucl.ac.uk cc: ggm@connect.com.au, carl@also.media.org, arlie@thepoint.net, kevin@cc.gatech.edu, rem-conf@es.net Message-ID: <4225643A.00370288.00@maskit1.vocaltec.co.il> Date: Mon, 10 Feb 1997 12:13:30 +0200 Subject: Re: MBone Community Size?, fragility of the MBone Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Scott Petrack 02/10/97 12:13 PM -------- On 02/10/97 06:51 AM GMT J.Crowcroft @ cs.ucl.ac.uk wrote: >video/audio content IS big business, but has stringent quality >expectations which the mbone cannot do... >actually, the quality issue is the same for the web - as soon as the underlying net can >deliver guaratees (e.g. ipsec, int-serv, type >guarantees) then the share delaers might think about serious use of >the public internet - just the same as the tv and radio people What is needed are not guarantees, just lots of bandwidth of decent quality. Television gives you no gurantees, neither do international Telephone calls, nor radio. What it does give you is enough decent-quality bandwidth that to be useful for the purpose. No gurantees. The Internet and multicast promise to offer the sorts of services that news, radio, television, etc. can offer, but on a global scale rather than the current local reach which is possible. For telephony and mail, it promises richer, more flexible, cheaper function. That's "all." The reasons that these things are not taking off is simply that there isn't enough bandwidth of the right quality. Of course, it might well be that the guarantess are an essential thing so that businesses can charge to get the money and incentive to upgrade the bandwidth. So it may be that we need guarantees to put in place the *financial* infrastructure to build up the internet. But it is not needed to insure usefulness of the service. Scott From rem-conf-request@es.net Mon Feb 10 13:26:10 1997 Received: from igate1.hac.com by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Feb 1997 10:25:32 -0800 Received: from ises01.ES.HAC.COM ([147.16.5.2]) by igate1.hac.com (8.8.4/8.8.4) with SMTP id KAA08487 for ; Mon, 10 Feb 1997 10:25:18 -0800 (PST) From: vbarajas@CCGATE.HAC.COM Received: by ises01.ES.HAC.COM; id AA03117; Mon, 10 Feb 1997 10:25:23 -0800 Received: from cc:Mail by CCGATE.HAC.COM id AA855599343; Mon, 10 Feb 97 10:23:59 PST8 Date: Mon, 10 Feb 97 10:23:59 PST8 Encoding: 8 Text Message-Id: <9701108555.AA855599343@CCGATE.HAC.COM> To: rem-conf@es.net Subject: Re: MBone Community and fragility ... Maybe we need to stop thinking of the web / MBONE as a product and realize they are really more a mode of transport. There may exist "better" transport mechanisims to convey the content of "the web" and MBone". In the process we may even improve the Internet's performance by using it for what it was designed for, two-way data transport. ......victor barajas From rem-conf-request@es.net Mon Feb 10 13:50:54 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Feb 1997 10:50:00 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id KAA02864 for ; Mon, 10 Feb 1997 10:50:11 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma002854; Mon Feb 10 10:49:49 1997 Received: by hille.msri.org (8.7/MSRI) id KAA03603; Mon, 10 Feb 1997 10:48:56 -0800 (PST) Date: Mon, 10 Feb 1997 10:48:56 -0800 (PST) Message-Id: <199702101848.KAA03603@hille.msri.org> To: rem-conf@es.net From: m1 Reply-to: m1@msri.org Subject: Jerry Marsden "Geometry and Classical Mechanics" MBone Broadcast Announcement ---------------------------- Title: Jerry Marsden "Geometry and Classical Mechanics" Date: Feb 18, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.math.washington.edu/~lee/PNGS/97-winter/marsden.html Description: One of the many problems that control theory addresses is that of feedback stabilization. A simple example illustrating what is meant is how humans learn to balance (that is, stabilize) when walking, riding bicycles, or to balance inverted broomsticks, or whirling a lasso. Related examples are the problem of stabilizing a spinning satellite and the reorientation problem for a springboard diver. This talk presents a general stabilization technique introduced by Bloch, Krishnaprasad, Marsden and Sanchez in the context of a rigid body with internal rotors. This technique is now known to result from a general Kaluza-Klein type of construction, familiar to geometers and physicists. Other examples, such as stabilizing an inverted pendulum on a cart, the dynamics of an underwater vehicle and the motion of a double spherical pendulum will also be discussed. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Mon Feb 10 13:52:50 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Feb 1997 10:51:59 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id KAA02911 for ; Mon, 10 Feb 1997 10:52:11 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma002906; Mon Feb 10 10:51:22 1997 Received: by hille.msri.org (8.7/MSRI) id KAA03637; Mon, 10 Feb 1997 10:50:30 -0800 (PST) Date: Mon, 10 Feb 1997 10:50:30 -0800 (PST) Message-Id: <199702101850.KAA03637@hille.msri.org> To: rem-conf@es.net From: m1 Reply-to: m1@msri.org Subject: Bill Thurston "Foliations and Geometry" MBone Broadcast Announcement ---------------------------- Title: Bill Thurston "Foliations and Geometry" Date: Feb 19, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.math.washington.edu/~lee/PNGS/97-winter/thurston.html Description: I will discuss progress in understanding the geometry of foliations, particularly in dimension 3, in connection with the program of trying to reconcile and combine several approaches toward three-dimensional topology. A main goal of the program is to find a construction for a geometric decomposition for a 3-manifold based on a taut foliation, an essential lamination, or a tight contact structure. An important related goal is to analyze how these structures relate to a hyperbolic structure. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Mon Feb 10 14:04:41 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Feb 1997 11:03:42 -0800 Received: from little-bear by precept.com (SMI-8.6/SMI-SVR4) id KAA10498; Mon, 10 Feb 1997 10:28:18 -0800 From: jcole@precept.com Message-Id: <970210102839.ZM3414@little-bear> Date: Mon, 10 Feb 1997 10:28:37 -0800 Reply-To: jcole@precept.com X-Mailer: Z-Mail 4.0 (4.0.0 Aug 21 1995) To: rem-conf@es.net Subject: MPEG Support In MBONE Tools Cc: vic@ee.lbl.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii I work for Precept software, and the next version of our IP/TV application will support serving and receiving MPEG audio/video using RTP MPEG elementary streams payload format (RFC 2038). Since IP/TV can interoperate with vic/vat and Apple's MBONE TV app I'm curious to know if anyone has ever attempted to roll support for MPEG video and audio into vic and vat? Currently the intersection is H261 video and 8kHz (PCM, DVI, GSM) audio. I'm not thinking of the public MBONE context, (where bandwidth and multicast support are significant hurdles to widesrpead deployment), but rather intranet environments at government, academic and corporate sites where a cross platform networked video solution is high on the "desired" list, and perhaps best served by different "standards-based" tools on the different platforms which can interoperate. We've been talking to folks in Apple's QuickTime TV engineering group, and they're considering adding support for MPEG to a future version of QuickTime TV which will interoperate with the MBONE tools. Anyone care to comment on the UNIX vic/vat front? Also am curious if H263 video will likely be added as a supported video type to vic anytime soon? -- John Cole, Systems Engineer Tel: 415.845.5217 Precept Software, Inc. Fax: 415.845.5235 1072 Arastradero Road http://www.precept.com Palo Alto, CA 94304 E-Mail: jcole@precept.com From rem-conf-request@es.net Mon Feb 10 14:07:57 1997 Received: from engr.orst.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Feb 1997 11:06:31 -0800 Received: from ia.ENGR.ORST.EDU (ia.ENGR.ORST.EDU [128.193.55.25]) by engr.orst.edu (8.8.5/8.8.5) with ESMTP id LAA18976 for ; Mon, 10 Feb 1997 11:06:30 -0800 (PST) Received: from localhost by ia.ENGR.ORST.EDU (1.39.111.2/ENGR-Client) id AA106941589; Mon, 10 Feb 1997 11:06:29 -0800 Date: Mon, 10 Feb 1997 11:06:29 -0800 (PST) From: Stephane Chatre Cc: rem-conf@es.net Subject: Question about RTCP in RFC1889 In-Reply-To: <4225643A.00370288.00@maskit1.vocaltec.co.il> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In RFC1889, on page 17: "The alignment requirement and a length field in the fixed part are included to make RTCP packets "stackable". Multiple RTCP packets may be concatenated without any intervening separators to form a compound RTCP packet that is sent in a single packet of the lower layer protocol, for example UDP. There is no explicit count of individual RTCP packets in the compound packet since the lower layer protocols are expected to provide an overall length to determine the end of the compound packet." This paragraph is a little ambiguous to me. Does the length field in the fixed part indicate how many RTCP packets have been concatenated to form the current one? Now, if as said, there is no explicit count, what does this length field stand for? If there is no explicit count, how can we know how many packets have been concatenated? By trying to parse what we receive? Thanks. ======================== Stephane Chatre Email: chatre@cs.orst.edu Department of Computer Science Phone: (541) 737-5583 (office) Oregon State University (541) 757-3376 (home) Life is what happens to you while you're busy making other plans. - John Lennon From rem-conf-request@es.net Mon Feb 10 15:55:57 1997 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Feb 1997 12:54:51 -0800 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id MAA12360; Mon, 10 Feb 1997 12:54:44 -0800 (PST) Message-Id: <199702102054.MAA12360@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: jcole@precept.com cc: rem-conf@es.net, vic@ee.lbl.gov Subject: Re: MPEG Support In MBONE Tools In-reply-to: Your message of "Mon, 10 Feb 1997 10:28:37 PST." <970210102839.ZM3414@little-bear> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Feb 1997 12:54:44 -0800 From: Amancio Hasty >From The Desk Of jcole@precept.com : > Also am curious if H263 video will likely be added as a supported video type > to vic anytime soon? Is there a publicly available H263 codec? My understanding is that H263 is a propieratory format which if used in a public domain tool one may have to pay royalties. The same goes for G.763 . Amancio From rem-conf-request@es.net Mon Feb 10 19:57:27 1997 Received: from zephyr.isi.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Feb 1997 16:56:40 -0800 Received: from can.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Mon, 10 Feb 1997 16:56:37 -0800 Date: Mon, 10 Feb 97 16:57:57 PST From: braden@isi.edu Posted-Date: Mon, 10 Feb 97 16:57:57 PST Message-Id: <9702110057.AA14526@can.isi.edu> Received: by can.isi.edu (4.1/4.0.3-6) id ; Mon, 10 Feb 97 16:57:57 PST To: Scott_Petrack@vocaltec.com Subject: Re: MBone Community Size?, fragility of the MBone Cc: ggm@connect.com.au, carl@also.media.org, arlie@thepoint.net, kevin@cc.gatech.edu, rem-conf@es.net *> What is needed are not guarantees, just lots of bandwidth of decent *> quality. Television gives you no gurantees, neither do international *> Telephone calls, nor radio. What it does give you is enough *> decent-quality bandwidth that to be useful for the purpose. No *> gurantees. *> Scott, Huh? That seems like a surprising statement. In fact, TV and radio operate with very rigid service guarantees. Each channel ("application") gets a carefully crafted and strictly guaranteed slice of the bandwidth. That seems to map pretty exactly into an int-serv type guarantee. What do you mean when you say "guarantee"?? Bob Braden *> The Internet and multicast promise to offer the sorts of services that *> news, radio, television, etc. can offer, but on a global scale rather *> than the current local reach which is possible. For telephony and mail, *> it promises richer, more flexible, cheaper function. *> *> That's "all." *> *> The reasons that these things are not taking off is simply that there *> isn't enough bandwidth of the right quality. *> *> Of course, it might well be that the guarantess are an essential thing *> so that businesses can charge to get the money and incentive to upgrade *> the bandwidth. So it may be that we need guarantees to put in place the *> *financial* infrastructure to build up the internet. But it is not *> needed to insure usefulness of the service. *> *> Scott *> *> *> From rem-conf-request@es.net Mon Feb 10 20:06:43 1997 Received: from broon.off.connect.com.au by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Feb 1997 17:05:58 -0800 Received: from connect.com.au (ggm@localhost) by broon.off.connect.com.au with ESMTP id LAA04873 (8.8.5/IDA-1.6); Tue, 11 Feb 1997 11:02:29 +1000 (EST) X-Authentication-Warning: broon.off.connect.com.au: ggm owned process doing -bs To: braden@isi.edu cc: Scott_Petrack@vocaltec.com, carl@also.media.org, arlie@thepoint.net, kevin@cc.gatech.edu, rem-conf@es.net Subject: Re: MBone Community Size?, fragility of the MBone In-reply-to: Your message of "Mon, 10 Feb 1997 16:57:57 PST." <9702110057.AA14526@can.isi.edu> Date: Tue, 11 Feb 1997 11:02:27 +1000 Message-ID: <4869.855622947@connect.com.au> From: George Michaelson Also interesting is the "QDU" concept which states what level of degredation can be introduced by compression or alternate delivery methods beyond which voice doesn't meet service level guarantees. I can't speak for how well it fits reality, but as a model of 'acceptable' distortion its interesting to think how this could fit into an IP model, perhaps layered codings could be exploited here to select "QDU-appropriate' versions for injection down thinner and thinner pipes? TV broadcasts certainly aim to present a dynamic range in audio which as near as possible "flat" and this presents interesting apparent shifts in volume as you alter from movie to ads to movie. Its quite plain when CNN and other offshore news sources are being sent down compressed channels, there is clear pixelization on the image when its zoomed in on by post-production, and the sound quality drop is very marked. I remember seeing TV engineers fiddling with old style orthicon cameras at BBC to get colour balance right, they were very prone to thermal shifts and there was a huge array of standard colourcards and adjustments to suit going on all the time. Clearly they regarded some level of self-consistency as important. I think all this goes to re-inforce Bobs comment: in the main TV sticks to very clear norms of message quality (ignoring meaning of content :-) cheers -George From rem-conf-request@es.net Mon Feb 10 20:14:48 1997 Received: from julia.mlds.com by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Feb 1997 17:13:20 -0800 Received: from Albert.gcast.com by julia.mlds.com (SMI-8.6/SMI-SVR4) id RAA14216; Mon, 10 Feb 1997 17:11:48 -0800 Received: by Albert.gcast.com with Microsoft Mail id <01BC1775.2BC9F700@Albert.gcast.com>; Mon, 10 Feb 1997 17:09:27 -0800 Message-ID: <01BC1775.2BC9F700@Albert.gcast.com> From: Albert Chen To: "'Scott_Petrack@vocaltec.com'" , "J.Crowcroft@cs.ucl.ac.uk" Cc: "ggm@connect.com.au" , "carl@also.media.org" , "arlie@thepoint.net" , "kevin@cc.gatech.edu" , "rem-conf@es.net" Subject: RE: MBone Community Size?, fragility of the MBone Date: Mon, 10 Feb 1997 17:09:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Scott, Television, radio and the telephone differ from the Internet and Mbone, = because they are networks dedicated to a specified number of sessions. = These sessions are the frequencies, channels or stations that are = administered to only one provider at a time. The Internet and Mbone are = packet switched networks, on which many session providers are = simultaneously vying for the same network resources. Guarantees on = delivery, or resource reservation, are necessary to provide high quality = presentation. In essence, there is bandwidth reservation on television = and radio, because there are no two stations sharing the same frequency = at the same time. Same with telephone, there is not more than one = conversation on any given circuit. The same needs to be done for the = Internet and Mbone. Not having enough bandwidth is just one part of the = problem. Regards, Albert Chen GlobalCast Communications -----Original Message----- From: Scott_Petrack@vocaltec.com [SMTP:Scott_Petrack@vocaltec.com] Sent: Monday, February 10, 1997 2:14 AM To: J.Crowcroft@cs.ucl.ac.uk Cc: ggm@connect.com.au; carl@also.media.org; arlie@thepoint.net; = kevin@cc.gatech.edu; rem-conf@es.net Subject: Re: MBone Community Size?, fragility of the MBone Scott Petrack 02/10/97 12:13 PM -------- On 02/10/97 06:51 AM GMT J.Crowcroft @ cs.ucl.ac.uk wrote: >video/audio content IS big business, but has stringent quality >expectations which the mbone cannot do... >actually, the quality issue is the same for the web - as soon as the underlying net can >deliver guaratees (e.g. ipsec, int-serv, type >guarantees) then the share delaers might think about serious use of >the public internet - just the same as the tv and radio people What is needed are not guarantees, just lots of bandwidth of decent quality. Television gives you no gurantees, neither do international Telephone calls, nor radio. What it does give you is enough decent-quality bandwidth that to be = useful for the purpose. No gurantees. The Internet and multicast promise to offer the sorts of services that news, radio, television, etc. can offer, but on a global scale rather than the = current local reach which is possible. For telephony and mail, it promises richer, more flexible, cheaper function. That's "all." The reasons that these things are not taking off is simply that there = isn't enough bandwidth of the right quality. Of course, it might well be that the guarantess are an essential thing = so that businesses can charge to get the money and incentive to upgrade the bandwidth. So = it may be that we need guarantees to put in place the *financial* infrastructure to build = up the internet. But it is not needed to insure usefulness of the service. Scott From rem-conf-request@es.net Mon Feb 10 20:38:59 1997 Received: from mail-out2.apple.com by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Feb 1997 17:37:37 -0800 Received: from scv3.apple.com (A17-128-100-121.apple.com [17.128.100.121]) by mail-out2.apple.com (8.8.5/8.8.4) with ESMTP id RAA104766 for ; Mon, 10 Feb 1997 17:36:02 -0800 Received: from mailman.apple.com.CPT (mailman.apple.com [17.206.40.179]) by scv3.apple.com (8.8.5/8.8.4) with SMTP id RAA21620 for ; Mon, 10 Feb 1997 17:38:05 -0800 Received: from [17.255.9.131] (skylawn.research.apple.com) by mailman.apple.com.CPT (4.1/SMI-4.1) id AA28501; Mon, 10 Feb 97 17:33:24 PST Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 10 Feb 1997 17:37:36 -0800 To: rem-conf@es.net From: alagu@mailman.apple.com (Alagu Periyannan) Subject: Re: Question about RTCP in RFC1889 At 11:06 AM 2/10/97, Stephane Chatre wrote: >In RFC1889, on page 17: > >"The alignment requirement and a length field in the fixed > part are included to make RTCP packets "stackable". Multiple RTCP > packets may be concatenated without any intervening separators to > form a compound RTCP packet that is sent in a single packet of the > lower layer protocol, for example UDP. There is no explicit count of > individual RTCP packets in the compound packet since the lower layer > protocols are expected to provide an overall length to determine the > end of the compound packet." > >This paragraph is a little ambiguous to me. >Does the length field in the fixed part indicate how many RTCP packets >have been concatenated to form the current one? >Now, if as said, there is no explicit count, what does this length field >stand for? If there is no explicit count, how can we know how many packets >have been concatenated? By trying to parse what we receive? > >Thanks. > My understanding is that the length field specifies the length of each RTCP packet. The sum of these lengths must add up to the UDP data length (after taking into account whether headers are included in the lengths?). The above paragraph essentially says that there is already enough information in the packet. Hence it is not necessary to send an explicit count of RTCP packets in a UDP packet. Alagu Periyannan alagu@mailman.apple.com Communications Products and Technology Apple Computer, Inc. From rem-conf-request@es.net Mon Feb 10 21:06:27 1997 Received: from engr.orst.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Feb 1997 18:05:00 -0800 Received: from ia.ENGR.ORST.EDU (ia.ENGR.ORST.EDU [128.193.55.25]) by engr.orst.edu (8.8.5/8.8.5) with ESMTP id SAA19321; Mon, 10 Feb 1997 18:04:59 -0800 (PST) Received: from localhost by ia.ENGR.ORST.EDU (1.39.111.2/ENGR-Client) id AA119956698; Mon, 10 Feb 1997 18:04:58 -0800 Date: Mon, 10 Feb 1997 18:04:58 -0800 (PST) From: Stephane Chatre Reply-To: Stephane Chatre To: Alagu Periyannan Cc: rem-conf@es.net Subject: Re: Question about RTCP in RFC1889 In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 10 Feb 1997, Alagu Periyannan wrote: > At 11:06 AM 2/10/97, Stephane Chatre wrote: > >In RFC1889, on page 17: > > > >"The alignment requirement and a length field in the fixed > > part are included to make RTCP packets "stackable". Multiple RTCP > > packets may be concatenated without any intervening separators to > > form a compound RTCP packet that is sent in a single packet of the > > lower layer protocol, for example UDP. There is no explicit count of > > individual RTCP packets in the compound packet since the lower layer > > protocols are expected to provide an overall length to determine the > > end of the compound packet." > > > >This paragraph is a little ambiguous to me. > >Does the length field in the fixed part indicate how many RTCP packets > >have been concatenated to form the current one? > >Now, if as said, there is no explicit count, what does this length field > >stand for? If there is no explicit count, how can we know how many packets > >have been concatenated? By trying to parse what we receive? > > > >Thanks. > > > > My understanding is that the length field specifies the length > of each RTCP packet. > > The sum of these lengths must add up to the UDP data length > (after taking into account whether headers are included in > the lengths?). > > The above paragraph essentially says that there is already enough > information in the packet. Hence it is not necessary to send an > explicit count of RTCP packets in a UDP packet. > > > > > Alagu Periyannan alagu@mailman.apple.com > > Communications Products and Technology > Apple Computer, Inc. > > > Thanks to all those who answered! Everything is clear now. The excerpt was already self-explanatory. Stephane ======================== Stephane Chatre Email: chatre@cs.orst.edu Department of Computer Science Phone: (541) 737-5583 (office) Oregon State University (541) 757-3376 (home) Life is what happens to you while you're busy making other plans. - John Lennon From rem-conf-request@es.net Mon Feb 10 23:58:16 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Feb 1997 20:57:04 -0800 Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id UAA13035; Mon, 10 Feb 1997 20:27:58 -0800 Date: Mon, 10 Feb 1997 20:29:13 -0800 () From: Stephen Casner To: Christian Zahl cc: rem-conf@es.net Subject: Re: Inconsistence in IP/UDP/RTP compression ID In-Reply-To: <199702072038.VAA07013@tao.fokus.gmd.de > Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Christian, I'll try to catch up with your collection of questions... > We are currently developing a method for transfering multiple > RTP streams over a low-bandwidth PPP connection. The implementaion > consists of an RTP mixer on both ends of the PPP link, which > adjust the payload-type field according to the bandwidth > available. So it can happen very often, How often? It seems to me that the rate will need to be limited in order to maintain stability (avoid oscillation). In particular, changes in the direction of increasing the data rate should not be done too quickly. How long an integration time is needed to measure the available bandwidth? Considering those factors, how many packets would be transmitted with one payload type before switching to another, and for what size packets? Putting those numbers together, then you could figure out the percentage overhead caused by the need to send the full RTP header, including what your expected CSRC list size would be, on a payload switch. If you have done this analysis, please tell us about the numbers. > Well it seems to be a little difficult to get a bit to indicate any > change in the PT field, but it would be very helpfull to it! > Otherwise it can happen, that the occupied bandwidth will be greater > when adjusting the payload, than if we don't do so! Not very helpfull. > > I think it makes more sense to shorten the session context id to > 7 bit and to add a P bit, which indicates a new octet with the > changed PT value. I think there would be a number of people uncomfortable about reducing the size of the context ID. You could use multiple contexts which differ only by the payload type value so that when the payload type changes you only have to switch to a different context ID rather than send the whold header. However, as the sequence number and timestamp will likely have large changes since the last time the new context was used, you'd have to send large deltas for them. > 2. CSRC change compression > Well as described above we use a mixer and expect several sources for > the outgoing media stream. The current ID says, that, when the CSRC > list changes, then the whole list has to be transmitted. Because there > are several sources and we can assume that they also change more > frequenctly, I think that sending the whole list ist very poor! Do you expect to have several sources active at once? Part of the motivation for the current CSRC design is the expectation that, for example in the cause of mixing an audio conference, most of the time there will be only one person talking so the CSRC list will contain only that one identifier. Now, your application might be quite different such that many sources are transmitting at once. If so, would they stop and start frequently, or would they be transmitting all the time such that the CSRC list wouldn't change? In particular, would the number of packets sent in whatever is equivalent to a "talkspurt" be small? If the number of packets is large enough, then the cost of sending the CSRC list at the beginning/end of a "talkspurt" is amortized. > I think if would be much better to send ONLY the CSRC entries which > have been changed, i.e. added or removed. Because the other side also > have knowledge of the current set of CSRC entries, it can decided > if the entry as to be add or the be removed. This results in much less > overhead than in the current ID. What you have proposed would work, although it would require adding one bit to the CC count in the compressed header so that, if the whole list changes, there is room to include all the old identifiers being removed and all the new ones being installed. However, I am concerned about a protocol mechanism that means "if you have this, delete it, but if you don't have it, keep it". The compressor could also wind up feeding the decompressor more than 15 identifiers, which it would not be able to forward in the decompressed packets. In the conferencing example I mentioned earlier, when one person stops talking and another person starts talking, your proposal would require a CSRC list with two entries whereas the current spec would require only one. I expect this case to be pretty common for mixers. > Ok I see. BTW, a very stupid question: how about the high byte > of the IPv4 header? Why isn't it used like the low byte for the > context-id? If you mean the IPv4 length field, it contains the "Generation" number. See section 5.3.2 of the IPv6 Header Compression spec. > Hm, perhaps; I don't see any difference between "Data field" and > "data field" ?! Anyway, because I'm not familar with IPv6, I didn't > know what the "Data field" is. What I meant was, the IPv6 Header Compression spec defines a specific field named "Data". Please note that the reference here is not to IPv6, but to the IPv6 Header Compression spec. > But as you wrote in the ID, the IP ID > field NORMALY increments by one, but it can also be used any other > algorithm or by the upper layer (as defined in RFC791). So when > the ID delta > 0x3fffff or <0, the FULL_HEADER packet HAVE to be > transmitted. The ID is only a 16-bit number, so the delta can't be > 0x3fffff or <0. Or, more precisely, any delta value can be encoded into 1 to 3 bytes by the specified encoding table. > Here is another real example: Linux 2-x seems to generate the IP-ID > a little bit different. The ID inclements by 1 but is send in > little-endian encoding, so the following sequence of IP-IDs can occur > without any loss of packages (I found this while looking into my > PPP trace some minutes ago): > IP-ID field > fe 00 > ff 00 > 00 01 - FULL_HEADER needed > 01 01 That's unfortunate, although legal, I guess. Can the purveyors of Linux be convinced to htonl() the IP ID field? > You can see that in this case the FULL_HEADER type is needed, because > the absolute value decreases when using the network-byte-order, > without any kind of packet loss. No, again, any 16-bit delta can be encoded. > Perhaps we should think about using negative values for the delta > values? BTW, the same can theoretically happen when two IP packets > arrive in the wrong order (packet N+1 first, then packet N). If this > happens often, then the compression has NO gain! So how about of > using INTs for the delta fields instead of UNSIGNEDs. Ok, this > will reduce the maximum transferable delta value in one byte to > +-63. If you think this is too less, then we can say: > o the 1 byte form is UNSIGNED > o the 2 and 3 byte forms are SIGNED At the IETF meeting, it was suggested that the delta encoding be specified as a table rather than a function, with the default value of the table being set according to the encoding currently in the spec. (This is as a precursor to a future capability to download a new table on a per-context basis for full entropy encoding.) Since there are some holes in the current encoding, I suggest using those for negative offsets. This keeps the encoding tuned for the common case of positive offsets, but handles a portion of the negative offsets with reasonable efficiency as well: Decimal Hex -16384 C0 00 00 : : -129 C0 3F 7F -128 80 00 : : -1 80 7F 0 00 : : 127 7F 128 80 80 : : 16383 BF FF 16384 C0 40 00 : : 4194303 FF FF FF Any delta < -16384 or > 4194303 would require a FULL_HEADER, COMPRESSED_NON_TCP or COMPRESSED_UDP packet type. This encoding still leaves one hole of size 128 from C0 3F 80 to C0 3F FF just to keep the logical (vs. arithmetic) relationship in the table. We could get 128 more negative numbers by sliding down the three-byte values instead. I don't know if that makes a significant difference. (Should be none if the algorithm is table-driven.) Comments, anyone? > Now sender A changes the payload-type. This forces the translator T to > send the packet as COMPRESSED_UDP instead of COMPRESSED_RTP. There > will arrive several questions: > o to which context do the outgoing packet belongs, cA or cB? > Do we have to create a new one? cA, because that is the matching context. > o will all other contexts belonging to this source (the > tanslator) will be invalidated (cA and cB) ? No, the contexts are all independent even though they have the same network address and ports. > On page 5 you can read: "COMPRESSED_UDP ... It redefines the SSRC field > of the (potential) RTP header...". So the SSRC field has no meaning > (in my understanding), because we cannot assume that we have an > RTP packet. No, the context is set assuming there is an RTP header following the UDP header. That is how the SSRC is set. In this example, the SSRC in cA will be set to the same value that it already had. > So we also cannot save any RTP header informations in the > context (right?). Therefore, we have lost any kind of synchronization > from the compressor to the decompressor regarding this RTP stream! > If so, this would result in sending a FULL_HEADER next, to resync. No, that's wrong. The COMPRESSED_UDP packet sets the RTP part of the context is set just the way the FULL_HEADER would have set it. The only difference is that FULL_HEADER also sets the IP and UDP portions of the context. > Or perhaps I have misunderstood one importand think: are contexts > for the COMPRESSED_RTP and COMPRESSED_UDP are totally indepndent? No. There are just 256 contexts (assuming one-byte context ID, which is all the November version of the draft specifies). > From one point of view this seems to make sense, but on the other > side, it seems to be impossible to have two different applications > using the same SRC and DST addresses and ports, so when we have an > RTP context, the UDP context is a subset of it, isn't it? Yes. When a UDP packet arrives, the compressor selects a context based on the SRC and DST addresses and ports plus the bytes that are in the SSRC position of what might be an RTP header. The context is saved at both the compressor and decompressor is the IP header, UDP header, and what might be an RTP header. If the protocol is not RTP, then the bytes in what would be the SSRC field will probably change all the time, which would gobble up all the contexts. When that happens, that set of SRC and DST addresses and ports is added to the negative cache so compression is not attempted on those packets. In the case of the translator, the SRC and DST addresses and ports may always be the same, but the SSRC field would be different for the different sources. If there are more than 256 sources, the context cache will have some amount of churn depending upon how often the sources trade off. Or, you can use 16-bit context IDs as described in the ipv6-hc draft (details to be added to the compressed RTP spec soon). > Stephen, perhaps you have an description what have to be sent in the > scenareo shown above. I think in this point the ID is a little bit > confusing :-) I'd appreciate any comments you might have on what additional information I should add to the document and where. -- Steve From rem-conf-request@es.net Tue Feb 11 00:55:00 1997 Received: from sumo.vocaltec.co.il by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Feb 1997 21:53:57 -0800 Received: from maskit1.vocaltec.co.il (patish.vocaltec.co.il [199.203.72.3]) by sumo.vocaltec.co.il (8.6.12/8.6.12) with SMTP id HAA17998; Tue, 11 Feb 1997 07:51:33 +0200 From: Scott_Petrack@vocaltec.com Received: by maskit1.vocaltec.co.il(Lotus SMTP MTA v1.05 (274.9 11-27-1996)) id 4225643B.002051DB ; Tue, 11 Feb 1997 07:53:01 +0200 X-Lotus-FromDomain: VOCALTEC To: rem-conf@es.net cc: albert@julia.gcast.com, ggm@connect.com.au, carl@also.media.org, arlie@thepoint.net, kevin@cc.gatech.edu, J.Crowcroft@cs.ucl.ac.uk Message-ID: <4225643B.001F43BF.00@maskit1.vocaltec.co.il> Date: Tue, 11 Feb 1997 07:52:57 +0200 Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Scott Petrack 02/11/97 07:52 AM Let me lump together parts of a few of the replies to clarify what I mean. Please forgive me for not attributing each thing to its original poster. ------------------------------------------- >In fact, TV and radio operate with >very rigid service guarantees. >Each channel ("application") gets a carefully crafted and strictly >guaranteed slice of the bandwidth. >That seems to map pretty exactly into an int-serv type guarantee. What >do you mean when you say "guarantee"?? >In essence, there is bandwidth reservation on television and radio, because there >are no two stations sharing the same frequency at the same time. Apportioning the spectrum is more like UDP port numbers than int-serv definitions or the end-to-end *guarantees* of RSVP. Spectrum is apportioned because without it the whole system wouldn't work at all - there would be no way to separate the different application streams. By guarantee I mean "end to end guarantee of service", of the kind that int-serv and RSVP together are going to enable. Because of many many factors both within and beyond human control (neighbouring buildings, aircraft, weather, the cheapo digitization and editing schemes used by my network, etc.), the thing that comes out of my box has usually pretty lousy quality. Of course I live in the third world and don't have cable, but even if I had cable, I don't have a *guarantee* of quality. I can't sue CNN if they use some horrible digitization scheme, and I can't sue anybody if because of poor weather I get bad reception on my radio, or because I like classical music and the transmitters are much weaker than the rock stations, so if I drive too far out of the city then I receive classical music much worse than rock music. There are many market pressures which give incentive to the providers to produce a decent image or sound in my house, but I get no *guarantees* at all. I have nothing against int-serv and friends (well, I do, but that's not the point here ;-)), but I do believe that guarantees and RSVP will not solve anything at all until there is enough bandwidth of high-enough quality. Please read on (especially about telephony ....) ------------------------------------------------------------- >Its quite plain when CNN and other offshore news sources are being sent >down compressed channels, there is clear pixelization on the image when >its zoomed in on by post-production, and the sound quality drop is very marked. And you certainly can't sue CNN or anybody else because of the quality drop. You have no guarantee at all. You just have some guys who are "trying their best", and who have serious market pressure to keep the quality up. No guarantees. BTW, I agree, you see and hear more and more awful digital imagery and audio on TV, precisely because it's cheaper to produce and they have no obligation to give you anything better >I remember seeing TV engineers fiddling with old style orthicon cameras >at BBC to get colour balance right, they were very prone to thermal shifts and >there was a huge array of standard colourcards and adjustments to suit going on >all the time. Clearly they regarded some level of self-consistency as important. I would even say, "they regarded the quality of end image and audio that came out your endpoint as important." They did their best. But they did not use any guarantees to force themselves to deliver that quality. >I think all this goes to re-inforce Bobs comment: in the main TV sticks >to very clear norms of message quality (ignoring meaning of content :-) I think that it does the opposite: it shows that the infrastructure has developed to ensure that the quality is "good enough" - but there are no *guarantees* that what will come out of your box has any delay/noise or other measureable quality characteristics. ------------------------------------------- >Same with telephone, there is not more than one conversation on any given circuit. I still get cross talk occasionally, but more important, I claim that telephony gives absolutely no guarantees of ANY kind. You can (and do) get long delays, lousy coders, high packet loss. Try making an international phone call and get music-on-hold, you'll hear about 20-30% packet loss because of the ECI boxes and silence deletion. This makes it difficult or impossible to make an international call over a modem. Competition has driven the prices and quality way down, and there is no carrier that I know that offers an phone call with a guaranteed delay or audio quality. (If there were I would actually use it, because it does happen that I need to make a modem call from the US to Israel occasionally for something sensitive). I note with interest that in the telephone world, the fastest growing segment is *mobile* stuff, which has terrible quality, and definitely offers a "best-effort" service only. No one is suggesting that we need guarantees there - we just need more bandwidth of higher quality so that best-effort will be "good enough." >Not having enough bandwidth is just one part of the problem. I agree, that's why in original note I said we need lots of "decent-quality bandwidth". The stuff has to be "good enough", like television or radio or telephone. What I don't need are guarantees (in the sense that I defined above). If int-serv were to be used as a way of measuring and comparing internet infrastructure, so that we can quantify and then improve quality of service, this would be a great thing. What worries me is that people are going to insist on *guarantees* for things that are not necessary and impossible to produce, and therefore they will decide that the whole internet thing isn't very useful. Scott (Petrack) P.S. Question for Miss Manners: Do I really need to send replies individually like everyone else does? Or is it enough to reply to rem-conf? Surely everyone who wrote subscribes to rem-conf, so a single reply to rem-conf is enough? From rem-conf-request@es.net Tue Feb 11 01:29:23 1997 Received: from sumo.vocaltec.co.il by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Feb 1997 22:28:09 -0800 Received: from maskit1.vocaltec.co.il (patish.vocaltec.co.il [199.203.72.3]) by sumo.vocaltec.co.il (8.6.12/8.6.12) with SMTP id IAA18168; Tue, 11 Feb 1997 08:26:00 +0200 From: Scott_Petrack@vocaltec.com Received: by maskit1.vocaltec.co.il(Lotus SMTP MTA v1.05 (274.9 11-27-1996)) id 4225643B.00237A6A ; Tue, 11 Feb 1997 08:27:30 +0200 X-Lotus-FromDomain: VOCALTEC To: rem-conf@es.net cc: albert@julia.gcast.com, ggm@connect.com.au, carl@also.media.org, arlie@thepoint.net, kevin@cc.gatech.edu, J.Crowcroft@cs.ucl.ac.uk Message-ID: <4225643B.001F43BF.00@maskit1.vocaltec.co.il> Date: Tue, 11 Feb 1997 08:27:24 +0200 Subject: RE: MBone Community Size?, fragility of the MBone Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Scott Petrack 02/11/97 08:27 AM Let me lump together parts of a few of the replies to clarify what I mean. Please forgive me for not attributing each thing to its original poster. ------------------------------------------- >In fact, TV and radio operate with >very rigid service guarantees. >Each channel ("application") gets a carefully crafted and strictly >guaranteed slice of the bandwidth. >That seems to map pretty exactly into an int-serv type guarantee. What >do you mean when you say "guarantee"?? >In essence, there is bandwidth reservation on television and radio, because there >are no two stations sharing the same frequency at the same time. Apportioning the spectrum is more like UDP port numbers than int-serv definitions or the end-to-end *guarantees* of RSVP. Spectrum is apportioned because without it the whole system wouldn't work at all - there would be no way to separate the different application streams. By guarantee I mean "end to end guarantee of service", of the kind that int-serv and RSVP together are going to enable. Because of many many factors both within and beyond human control (neighbouring buildings, aircraft, weather, the cheapo digitization and editing schemes used by my network, etc.), the thing that comes out of my box has usually pretty lousy quality. Of course I live in the third world and don't have cable, but even if I had cable, I don't have a *guarantee* of quality. I can't sue CNN if they use some horrible digitization scheme, and I can't sue anybody if because of poor weather I get bad reception on my radio, or because I like classical music and the transmitters are much weaker than the rock stations, so if I drive too far out of the city then I receive classical music much worse than rock music. There are many market pressures which give incentive to the providers to produce a decent image or sound in my house, but I get no *guarantees* at all. I have nothing against int-serv and friends (well, I do, but that's not the point here ;-)), but I do believe that guarantees and RSVP will not solve anything at all until there is enough bandwidth of high-enough quality. Please read on (especially about telephony ....) ------------------------------------------------------------- >Its quite plain when CNN and other offshore news sources are being sent >down compressed channels, there is clear pixelization on the image when >its zoomed in on by post-production, and the sound quality drop is very marked. And you certainly can't sue CNN or anybody else because of the quality drop. You have no guarantee at all. You just have some guys who are "trying their best", and who have serious market pressure to keep the quality up. No guarantees. BTW, I agree, you see and hear more and more awful digital imagery and audio on TV, precisely because it's cheaper to produce and they have no obligation to give you anything better >I remember seeing TV engineers fiddling with old style orthicon cameras >at BBC to get colour balance right, they were very prone to thermal shifts and >there was a huge array of standard colourcards and adjustments to suit going on >all the time. Clearly they regarded some level of self-consistency as important. I would even say, "they regarded the quality of end image and audio that came out your endpoint as important." They did their best. But they did not use any guarantees to force themselves to deliver that quality. >I think all this goes to re-inforce Bobs comment: in the main TV sticks >to very clear norms of message quality (ignoring meaning of content :-) I think that it does the opposite: it shows that the infrastructure has developed to ensure that the quality is "good enough" - but there are no *guarantees* that what will come out of your box has any delay/noise or other measureable quality characteristics. ------------------------------------------- >Same with telephone, there is not more than one conversation on any given circuit. I still get cross talk occasionally, but more important, I claim that telephony gives absolutely no guarantees of ANY kind. You can (and do) get long delays, lousy coders, high packet loss. Try making an international phone call and get music-on-hold, you'll hear about 20-30% packet loss because of the ECI boxes and silence deletion. This makes it difficult or impossible to make an international call over a modem. Competition has driven the prices and quality way down, and there is no carrier that I know that offers an phone call with a guaranteed delay or audio quality. (If there were I would actually use it, because it does happen that I need to make a modem call from the US to Israel occasionally for something sensitive). I note with interest that in the telephone world, the fastest growing segment is *mobile* stuff, which has terrible quality, and definitely offers a "best-effort" service only. No one is suggesting that we need guarantees there - we just need more bandwidth of higher quality so that best-effort will be "good enough." >Not having enough bandwidth is just one part of the problem. I agree, that's why in original note I said we need lots of "decent-quality bandwidth". The stuff has to be "good enough", like television or radio or telephone. What I don't need are guarantees (in the sense that I defined above). If int-serv were to be used as a way of measuring and comparing internet infrastructure, so that we can quantify and then improve quality of service, this would be a great thing. What worries me is that people are going to insist on *guarantees* for things that are not necessary and impossible to produce, and therefore they will decide that the whole internet thing isn't very useful. Scott (Petrack) P.S. Question for Miss Manners: Do I really need to send replies individually like everyone else does? Or is it enough to reply to rem-conf? Surely everyone who wrote subscribes to rem-conf, so a single reply to rem-conf is enough? From rem-conf-request@es.net Tue Feb 11 10:13:02 1997 Received: from heaton.cl.cam.ac.uk by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Feb 1997 07:12:11 -0800 Received: from cl.cam.ac.uk [128.232.0.105] (pb) by heaton.cl.cam.ac.uk with esmtp (Exim 1.59 #2) id 0vuJsA-00039W-00; Tue, 11 Feb 1997 15:11:54 +0000 X-Mailer: exmh version 2.0gamma+CL 97/01/24 To: mbone@isi.edu Cc: rem-conf@es.net, mbone-seminars@cl.cam.ac.uk Subject: Any *FIRST HAND* use of Linux Boxes to source MBone video ? X-uri: X-face: &@N3QE9h|>f`igFCkZ'a1`z=nNLXb}k>H(79G"V?@!&*yn)uhPBctF1vc}LD'{OA%$bs X+l[wN,I^G8kKj2NFxQrr@1C4QBC]hq5-%ZkV,^Zl/qE<0`zCQ1nM+]-N<^WG[H)]?d) A:L9AFgOU[BjbaY)uBAMz}h!fm^O0# Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Piete Brooks Reply-to: mbone-seminars@cl.cam.ac.uk Date: Tue, 11 Feb 1997 15:11:51 +0000 Sender: Piete.Brooks@cl.cam.ac.uk Message-Id: We have a very old and slow dec3000/300lx running osf1_3.2D with a J300 board which we use to transmit our Security Seminars (using nv, as it won't work unver vic) which we'd like to replace with a linux box and frame grabber. A member of the dept bought a Matrox Millenium so that they could source video, but so far they've been unable to get it to work as Matrox will not release the necessary info to write a Linux driver :-((( SO: is anyone using a Linux box to transmit video to the MBone using available hardware and an external video source (Quick Cam is not sifficient !) ? If so, PLEASE let me know ! From rem-conf-request@es.net Tue Feb 11 10:31:20 1997 Received: from concorde.inria.fr by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Feb 1997 07:29:54 -0800 Received: from maillol.inria.fr (maillol.inria.fr [128.93.25.14]) by concorde.inria.fr (8.7.6/8.7.3) with ESMTP id QAA17941; Tue, 11 Feb 1997 16:28:52 +0100 (MET) Received: (from liao@localhost) by maillol.inria.fr (8.7.6/8.7.3) id QAA15917; Tue, 11 Feb 1997 16:26:50 +0100 (MET) Date: Tue, 11 Feb 1997 16:26:50 +0100 (MET) Message-Id: <199702111526.QAA15917@maillol.inria.fr> From: Tie Liao To: java-networking@cdt.luth.se, rem-conf@es.net Cc: Bernard.Martin@inria.fr, Jean-Francois.Abramatic@inria.fr, Yves.Peynaud@inria.fr, Catherine.Chat@inria.fr, Patrick.Duval@inria.fr, Philipp.Hoschka@inria.fr, rodgers@nlm.nih.gov, jct@edelweb.fr, Benoit.Boute@enst.fr, likavec@igd.fhg.de, Christian.Donot@inria.fr, Tie.Liao@inria.fr Subject: Announce: WebCanal - a Mutlicast Web Application Reply-to: Tie.Liao@inria.fr Sorry if you receive two times the same message. ====================================================================== We are pleased to announce that a multicast web application - WebCanal is made available on our ftp site. This application, developed by INRIA, is still in a beta test version. It is aimed at sharing your web pages on the MBONE, either they are maintained on a Web server or just stored as local files. The main features include: o broadcast documents in a multicast channel, for example, broadcast latest news or update common files. This can be performed as a background task. o interactively exchange documents with other users in a multicast session using a web browser. o all received documents are cached and can be reviewed. o document transfer is optimized so that unnecessary document transfer is generally avoided. WebCanal is designed to be network friendly, it can work at low bit rate for most Web documents including small inlined images. WebCanal is based on the Light-weight Reliable Multicast Protocol (LRMP) which makes use of the NACK mechanism described in SRM. But it is not a simple copy of SRM, it also addresses the problems related to packet ordering and rate based flow control. WebCanal is implemented in Java and requires JDK1.1 to run. To download the package, please go to: ftp://ftp.inria.fr/INRIA/Actions/webcanal This directory includes mainly the following files: webcanal-1.0b.tar.gz - the binary files, documentation, etc. It should be enough for most users. webcanal-1.0b.src.tar.gz - the source package. See the copyright notice included in the package for copyright information. For other information, please look at: http://monet.inria.fr/ Suggestions and questions could be sent to Tie.Liao@inria.fr Date: Tue Feb 11 14:49:39 MET 1997 From rem-conf-request@es.net Tue Feb 11 11:23:21 1997 Received: from silver.sms.fi by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Feb 1997 08:22:34 -0800 Received: (from pete@localhost) by silver.sms.fi (8.8.5/8.7.3) id SAA07044; Tue, 11 Feb 1997 18:22:06 +0200 (EET) Date: Tue, 11 Feb 1997 18:22:06 +0200 (EET) Message-Id: <199702111622.SAA07044@silver.sms.fi> From: Petri Helenius To: mbone-seminars@cl.cam.ac.uk Cc: mbone@isi.edu, rem-conf@es.net Subject: Any *FIRST HAND* use of Linux Boxes to source MBone video ? In-Reply-To: References: Piete Brooks writes: > We have a very old and slow dec3000/300lx running osf1_3.2D with a J300 board > which we use to transmit our Security Seminars (using nv, as it won't work > unver vic) which we'd like to replace with a linux box and frame grabber. > > A member of the dept bought a Matrox Millenium so that they could source > video, but so far they've been unable to get it to work as Matrox will not > release the necessary info to write a Linux driver :-((( Matrox Millenium is a display board, you don't get it to source video even if you would have all the information on the card. So I assume you must be talking about Matrox Meteor. > > SO: is anyone using a Linux box to transmit video to the MBone using available > hardware and an external video source (Quick Cam is not sifficient !) ? > If so, PLEASE let me know ! > So since you have the hardware only thing you have to do is to upgrade the software. Install FreeBSD and the Meteor support will come with it. Pete From rem-conf-request@es.net Tue Feb 11 11:34:14 1997 Received: from tis-mail.thepoint.net (actually tis-backup.thepoint.net) by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Feb 1997 08:30:24 -0800 Received: by tis-mail.thepoint.net with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC180E.EAA28720@tis-mail.thepoint.net>; Tue, 11 Feb 1997 11:30:00 -0500 Message-ID: From: Arlie Davis To: "'Scott_Petrack@vocaltec.com'" Cc: "'rem-conf@es.net'" Subject: RE: Date: Tue, 11 Feb 1997 11:29:58 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >---------- >From: Scott_Petrack@vocaltec.com >Sent: Tuesday, February 11, 1997 12:52 AM >To: rem-conf@es.net >Cc: Arlie Davis; albert@julia.gcast.com; ggm@connect.com.au; >carl@also.media.org; kevin@cc.gatech.edu; J.Crowcroft@cs.ucl.ac.uk > >Apportioning the spectrum is more like UDP port numbers than int-serv >definitions >or the end-to-end *guarantees* of RSVP. I strongly disagree. True, spectrum allocation serves to distinguish the services / channels, like UDP port numbers. However, one station can send as much "traffic" as its wants without ever interfering with any other station at all. This stands in stark contrast to UDP, where one source can easily overwhelm (or render useless) all other sources. > From rem-conf-request@es.net Tue Feb 11 11:36:19 1997 Received: from web.AEC.at by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Feb 1997 08:33:49 -0800 Received: (from oliver@localhost) by web.AEC.at (8.8.3/8.7) id QAA31389; Tue, 11 Feb 1997 16:32:39 +0100 Date: Tue, 11 Feb 1997 16:32:38 +0100 (MET) From: Oliver Frommel To: Petri Helenius cc: mbone-seminars@cl.cam.ac.uk, mbone@isi.edu, rem-conf@es.net Subject: Re: Any *FIRST HAND* use of Linux Boxes to source MBone video ? In-Reply-To: <199702111622.SAA07044@silver.sms.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 11 Feb 1997, Petri Helenius wrote: > Piete Brooks writes: > > We have a very old and slow dec3000/300lx running osf1_3.2D with a J300 board > > which we use to transmit our Security Seminars (using nv, as it won't work > > unver vic) which we'd like to replace with a linux box and frame grabber. > > > > A member of the dept bought a Matrox Millenium so that they could source > > video, but so far they've been unable to get it to work as Matrox will not > > release the necessary info to write a Linux driver :-((( > > Matrox Millenium is a display board, you don't get it to source video > even if you would have all the information on the card. So I assume > you must be talking about Matrox Meteor. > > > > SO: is anyone using a Linux box to transmit video to the MBone using available > > hardware and an external video source (Quick Cam is not sifficient !) ? > > If so, PLEASE let me know ! > > > So since you have the hardware only thing you have to do is to upgrade > the software. Install FreeBSD and the Meteor support will come with > it. Linux does also support the MAtrox Meteor .. take a look at sunsite.unc.edu's Linux archive directory apps/video: meteor-1.4a.tgz driver for the matrox meteor frame grabber card oliver From rem-conf-request@es.net Tue Feb 11 12:02:45 1997 Received: from antares.utu.fi by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Feb 1997 09:01:29 -0800 Received: by utu.fi id <30983-21892>; Tue, 11 Feb 1997 19:00:43 +0200 Subject: Re: Any *FIRST HAND* use of Linux Boxes to source MBone video ? From: Matti Aarnio To: pete@sms.fi (Petri Helenius) Date: Tue, 11 Feb 1997 19:00:39 +0200 (EET) Cc: mbone-seminars@cl.cam.ac.uk, mbone@isi.edu, rem-conf@es.net In-Reply-To: <199702111622.SAA07044@silver.sms.fi> from "Petri Helenius" at Feb 11, 97 06:22:06 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 1766 Message-Id: <19970211170043Z30983-21892+1043@utu.fi> Petri Helenius writes: > Piete Brooks writes: ... > Matrox Millenium is a display board, you don't get it to source video > even if you would have all the information on the card. So I assume > you must be talking about Matrox Meteor. > > SO: is anyone using a Linux box to transmit video to the MBone using available > > hardware and an external video source (Quick Cam is not sifficient !) ? > > If so, PLEASE let me know ! > > > So since you have the hardware only thing you have to do is to upgrade > the software. Install FreeBSD and the Meteor support will come with it Or pick proper driver: ---- /pub/mirrors/sunsite.unc.edu/pub/Linux/apps/video/meteor-1.4a.lsm ---- Begin3 Title: meteor Version: 1.4a Entered-date: 05SEP96 Description: A driver for the matrox meteor frame grabber card, as a kernel module. This is a port from the FreeBSD driver. Keywords: meteor, driver, video, frame grabber, matrox, module Author: (Jim Lowe, Mark Tinguely, Jim Bray) Maintained-by: ian@robots.ox.ac.uk Primary-site: ftp.rwii.com /pub/linux/system/Meteor 52959 meteor-1.4a.tgz Alternate-site: sunsite.unc.edu /pub/Linux/apps/video 52959 meteor-1.4a.tgz Original-site: joy.cs.ndsu.nodak.edu /pub 39621 meteor.1.11.tgz Platforms: kernel 1.3.72 and later with the (provided) bigphysarea patch by Matt Welsh Obviously a Matrox Meteor frame grabber card. Copying-policy: (C) End > Pete I recall a friend of mine told me on friday that he has integrated Meteor driver into vic 2.8. I must get it for storing into ftp://ftp.funet.fi/pub/networking/services/multicast/LINUX/ subtree.. /Matti Aarnio From rem-conf-request@es.net Tue Feb 11 17:02:24 1997 Received: from sirius.ctr.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Feb 1997 14:01:33 -0800 Received: from orion (orion.ctr.columbia.edu [128.59.68.28]) by sirius.ctr.columbia.edu (8.8.5/8.6.4.287) with SMTP id RAA23046; Tue, 11 Feb 1997 17:01:21 -0500 (EST) Sender: liao@ctr.columbia.edu Message-ID: <3300EC30.4EE4@ctr.columbia.edu> Date: Tue, 11 Feb 1997 17:01:20 -0500 From: Raymond Liao Organization: CTR, Columbia University X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: rem-conf@es.net CC: mnl@ctr.columbia.edu Subject: Seminar: H. Shulzrinne, "RTP Scaling over Very Large Groups" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MBone Broadcast Announcement Title: RTP SCALING FOR VERY LARGE GROUPS Speaker: Prof. Henning Schulzrinne Columbia University Date: Friday, January 24, 1997 Time: 10:00 AM - 11:00 AM EST Multicast Address: audio: DVI, RTP, 224.2.243.158/30528/127 video: H.261, RTP, 224.2.154.154/59442/127 Contact: Andrew T. Campbell (campbell@ctr.columbia.edu) URL: http://comet.ctr.columbia.edu/activities/seminars/ Place: Multimedia Network Laboratory 8LE1 Schapiro Research Building Center for Telecommunications Research Columbia University New York City, USA Abstract: We describe, analyze and simulate algorithms that allow scaling of feedback in very large multicast groups with potentially millions of members, both for any-to-any feedback and any-to-one feedback. While the techniques generalize, our particular focus is on feedback mechanisms suitable for the real-time transport protocol (RTP). To suppress the initial flood of packets occuring when a large number of users simultaneously join a session, we propose a new, but backward-compatible algorithm, called reconsideration, which minimizes the initial transient. Another algorithm quickly ``teaches'' new arrivals to a group the current group size. We then describe polling (any-to-one) algorithms that quickly estimate multicast populations. Adaptive statistical sampling may be used to reduce the state storage overhead incurred by tracking large user populations for either polling or the reconsideration algorithms. -- Raymond R.-F. Liao (212) 939-7158 http://www.ctr.columbia.edu/~liao Center for Telecommunications Research, Columbia University From rem-conf-request@es.net Tue Feb 11 17:10:29 1997 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Feb 1997 14:09:39 -0800 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id OAA22638; Tue, 11 Feb 1997 14:09:15 -0800 (PST) Message-Id: <199702112209.OAA22638@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: mbone-seminars@cl.cam.ac.uk cc: mbone@isi.edu, rem-conf@es.net Subject: Re: Any *FIRST HAND* use of Linux Boxes to source MBone video ? In-reply-to: Your message of "Tue, 11 Feb 1997 15:11:51 GMT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Feb 1997 14:09:15 -0800 From: Amancio Hasty >From The Desk Of Piete Brooks : > We have a very old and slow dec3000/300lx running osf1_3.2D with a J300 board > which we use to transmit our Security Seminars (using nv, as it won't work > unver vic) which we'd like to replace with a linux box and frame grabber. Well, there is a matrox meteor driver that comes with FreeBSD;additionally, the FreeBSD Matrox Meteor has been ported to Linux. It is kind of nice that the driver is available for both platforms because we can benefit >from bug fixes and enhancements. As for programming info, the Matrox Meteor is a simple video capture which has to chipsets : Philips SAA 7116 and SAA 7196 . So to learn how to program the Meteor you can download the docs for those chipsets >from Philips Web Site. I wrote a device driver for the Intel Smart Video Recorder III with sufficient functionality to support vic as well as my simple video tool "tv" which I use to watch TV on my system. The driver is based upon the Matrox Meteor one so it uses the exact same interface;however, I must warn you that the SAA 7196 and the Bt848 are very different chipsets. There is no PAL support however it should not be difficult to add PAL support. The readme file has contact info for getting the programming docs for the card. Architectually, the driver is very simple and should not be difficult to port to Linux. The driver is really for the BrookTree Bt848 chipset which means that it should work with any Bt848 chipset based boards such as the Hauppauge's Wincast/tv. One of the FreeBSD users reported great success with the WinCast/tv card on the first try. The driver is available at : ftp://rah.star-gate.com/pub/bt848.tar.gz The driver so far works best with Triton based motherboards and to a lesser extent with Natoma chipset based motherboards. For instance, I can get smooth video at 640x480 32bits on my P100 / Triton system but a few more dma errors on my PPRO 200Mhz /Natoma system. It is fairly safe to assume that the Natoma chipset is having problems with substain high video data rate. Last but not least the primary motivation for writing the Bt848 driver is that the SAA 7116 is not PCI 2.1 compliant and in certain instances can lock up solid a PPRO / Natoma system. Yes, I know the work around that some have found however independent tests on my PPRO systems shows that it can still crash a PPRO 200Mhz system. Amancio From rem-conf-request@es.net Tue Feb 11 17:13:25 1997 Received: from sirius.ctr.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Feb 1997 14:12:47 -0800 Received: from orion (orion.ctr.columbia.edu [128.59.68.28]) by sirius.ctr.columbia.edu (8.8.5/8.6.4.287) with SMTP id RAA23274; Tue, 11 Feb 1997 17:12:41 -0500 (EST) Sender: liao@ctr.columbia.edu Message-ID: <3300EED8.7629@ctr.columbia.edu> Date: Tue, 11 Feb 1997 17:12:40 -0500 From: Raymond Liao Organization: CTR, Columbia University X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: rem-conf@es.net CC: mnl@ctr.columbia.edu Subject: Resent: Seminar: H. Schulzrinne "RTP Scaling for Very Large Groups Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry for the resent, the date was wrong. ================================================================= MBone Broadcast Announcement Title: RTP SCALING FOR VERY LARGE GROUPS Speaker: Prof. Henning Schulzrinne Columbia University Date: Thursday, Feb. 13, 1997 Time: 10:00 AM - 11:00 AM EST Multicast Address: audio: DVI, RTP, 224.2.243.158/30528/127 video: H.261, RTP, 224.2.154.154/59442/127 Contact: Andrew T. Campbell (campbell@ctr.columbia.edu) URL: http://comet.ctr.columbia.edu/activities/seminars/ Place: Multimedia Network Laboratory 8LE1 Schapiro Research Building Center for Telecommunications Research Columbia University New York City, USA Abstract: We describe, analyze and simulate algorithms that allow scaling of feedback in very large multicast groups with potentially millions of members, both for any-to-any feedback and any-to-one feedback. While the techniques generalize, our particular focus is on feedback mechanisms suitable for the real-time transport protocol (RTP). To suppress the initial flood of packets occuring when a large number of users simultaneously join a session, we propose a new, but backward-compatible algorithm, called reconsideration, which minimizes the initial transient. Another algorithm quickly ``teaches'' new arrivals to a group the current group size. We then describe polling (any-to-one) algorithms that quickly estimate multicast populations. Adaptive statistical sampling may be used to reduce the state storage overhead incurred by tracking large user populations for either polling or the reconsideration algorithms. -- Raymond R.-F. Liao (212) 939-7158 http://www.ctr.columbia.edu/~liao Center for Telecommunications Research, Columbia University From rem-conf-request@es.net Tue Feb 11 19:32:16 1997 Received: from zephyr.isi.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Feb 1997 16:31:36 -0800 Received: from can.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 11 Feb 1997 16:31:32 -0800 Date: Tue, 11 Feb 97 16:32:53 PST From: braden@isi.edu Posted-Date: Tue, 11 Feb 97 16:32:53 PST Message-Id: <9702120032.AA15986@can.isi.edu> Received: by can.isi.edu (4.1/4.0.3-6) id ; Tue, 11 Feb 97 16:32:53 PST To: rem-conf@es.net, Scott_Petrack@vocaltec.com Cc: braden@ISI.EDU *> *> Apportioning the spectrum is more like UDP port numbers than int-serv *> definitions or the end-to-end *guarantees* of RSVP. Spectrum is *> apportioned because without it the whole system wouldn't work at all - *> there would be no way to separate the different application streams. *> Scott, That is a good point. In analog transmission spectrum dedication serves TWO functions: "addressing" as well as guarantee of non-interference from other signals. *> By guarantee I mean "end to end guarantee of service", of the kind that *> int-serv and RSVP together are going to enable. Because of many many *> factors both within and beyond human control (neighbouring buildings, *> aircraft, weather, the cheapo digitization and editing schemes used by *> my network, etc.), the thing that comes out of my box has usually *> pretty lousy quality. Of course I live in the third world and don't *> have cable, but even if I had cable, I don't have a *guarantee* of *> quality. I can't sue CNN if they use some horrible digitization scheme, *> and I can't sue anybody if because of poor weather I get bad reception *> on my radio, or because I like classical music and the transmitters are *> much weaker than the rock stations, so if I drive too far out of the *> city then I receive classical music much worse than rock music. Integrated service guarantees are essentially of dedicated bandwidth, though it is packaged as a bound on queueing delay. They give no guarantee of reliability (bits can still be dropped) or of quality of the data (the sender can be doing bad things). So the parallel is still pretty strong to radio or TV. [I am pursuing this point because there has been a tendency to assume too much about the "guarantees" of integrated service; another version of this confusion is a huge overloading of the term QoS.] *> *> >I think all this goes to re-inforce Bobs comment: in the main TV sticks *> >to very clear norms of message quality (ignoring meaning of content :-) *> *> I think that it does the opposite: it shows that the infrastructure has *> developed to ensure that the quality is "good enough" - but there are no *> *guarantees* that what will come out of your box has any delay/noise or *> other measureable quality characteristics. *> I guess we are at a stand-still here, but I will say it again: "Good enough" is exactly what the inventors of integrated services hope to provide you on the Internet. *> *> P.S. Question for Miss Manners: *> *> Do I really need to send replies individually like everyone else does? *> Or is it enough to reply to rem-conf? Surely everyone who wrote subscribes *> to rem-conf, so a single reply to rem-conf is enough? *> Do what works best for you. Bob Braden From rem-conf-request@es.net Tue Feb 11 19:39:00 1997 Received: from broon.off.connect.com.au by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Feb 1997 16:38:23 -0800 Received: from connect.com.au (ggm@localhost) by broon.off.connect.com.au with ESMTP id KAA29588 (8.8.5/IDA-1.6 for ); Wed, 12 Feb 1997 10:38:20 +1000 (EST) X-Authentication-Warning: broon.off.connect.com.au: ggm owned process doing -bs To: rem-conf@es.net Subject: Re: MBone Community Size?, fragility of the MBone In-reply-to: Your message of "Tue, 11 Feb 1997 08:27:24 +0200." <4225643B.001F43BF.00@maskit1.vocaltec.co.il> Date: Wed, 12 Feb 1997 10:38:18 +1000 Message-ID: <29586.855707898@connect.com.au> From: George Michaelson Ok. I'd like to revise my comments a bit. In the case of TV, quality is a mixed meaning word. At the source end, before transmission is introduced, I believe TV signals and aspects of that signal such as colour balance, soundmix, relative signal strength etc etc is managed under pretty rigorous specs. This is as much a function of history as anything else since signal loss under digital method should be much smaller than the requirements to control this kind of quality, but allowing for tape based methods of storage and edit, there is a quality loss issue in creating the final image, and they *need* that kind of QA to ensure the final product is what they loosely call 'broadcast quality'. Broadly speaking this is the same as the QDU issue for telecomms, but its pre-transmission stuff. When I've talked to the next rung down, the professional video production teams doing private video production for corporates and the like, the issue is the same but the compromises are a bit more lax. The discussion is usually about how S-VHS is now viable compared to betacamPRO, and that non-linear edit on S-VHS is as good as traditional edit on a betacam edit suite. The broadcasters would not regard S-VHS as being what they call 'broadcast quality' yet (I'd be very happy to be proven wrong) Once transmission is introduced, there is still a QA issue. The transmission engineers are pretty active in terms of monitoring signal quality and in attempting adjustments of antenna design and signal injection to overcome physical limits. In the UK, this often used to take the form of helping communities achieve a viable group aerial to overcome local problems. In Australia, its about regional upgrades to transform VHF to UHF, or to increase availablility beyond one merged channel of commercial plus the national public broadcaster. Its interesting to think about how they do this given the lack of a real feedback channel in the broadcast method. Perhaps they don't formalize it, but do in fact have a TV picking up the real signal and not showing foldback from the source. I sure hope so. However we *are* talking about a unidirectional protocol, with no flow control or feedback. Its not plausible to say there are going to be the quality issues you get from having something like RTCP in the loop. I suspect that the UDLR people are likely to say similar things, that the encodings used to send material should attempt to provide redundancy and alternate codings to permit the final product to get as close as possible to the sent content, but that for some people, reception is always an approximation. Jon comments that you can't say there is consistent quality comparing PAL to SECAM to NTSC. I think that within each standard, you'd find the standard attempted to define what (hah) gracefull failure each should display under signal loss, and what were considered the key content. In the case of NTSC clearly motion is favoured over chroma for instance. In the case of PAL I believe the encoding was designed to permit b&w signal to exist as a parasite under colour encoding so the existing user-base didn't have a major upgrade hassle (excluding the VHF-UHF transition) Does anybody expect that under digital TV we'll see reception reports come in as a feature, to permit the broadcasters to monitor real reception quality and make live adjustment? One imagines that MPEG can display highly differential quality under the variety of motion which is subject/edit dependant, and that you could fiddle the knobs on the compression box to attempt to preserve motion aspects at the cost of total bitrate for sports but pull it back for other forms of media. -George From rem-conf-request@es.net Wed Feb 12 02:14:34 1997 Received: from obelix.hrz.tu-chemnitz.de by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Feb 1997 23:13:56 -0800 Received: from sunnyboy.informatik.tu-chemnitz.de by obelix.hrz.tu-chemnitz.de with Local SMTP (PP) id <24120-0@obelix.hrz.tu-chemnitz.de>; Wed, 12 Feb 1997 08:13:11 +0100 Received: from rhea.informatik.tu-chemnitz.de (rhea.informatik.tu-chemnitz.de [134.109.192.140]) by sunnyboy.informatik.tu-chemnitz.de (8.8.4/8.7.3) with SMTP id IAA11051; Wed, 12 Feb 1997 08:13:42 +0100 (MET) Date: Wed, 12 Feb 1997 08:13:40 +0100 (MET) From: Dietrich Thie To: Piete Brooks cc: mbone@isi.edu, rem-conf@es.net Subject: Re: Any *FIRST HAND* use of Linux Boxes to source MBone video ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 11 Feb 1997, Piete Brooks wrote: > We have a very old and slow dec3000/300lx running osf1_3.2D with a J300 board > which we use to transmit our Security Seminars (using nv, as it won't work > unver vic) which we'd like to replace with a linux box and frame grabber. > > A member of the dept bought a Matrox Millenium so that they could source > video, but so far they've been unable to get it to work as Matrox will not > release the necessary info to write a Linux driver :-((( As far as I know, XFree86 3.2 supports Matrox Millenium, see http://www.bf.rmit.edu.au/~ajv/xf86-matrox.html if it is a Millenium with frame grabber modul, you are right, the modul is not supported yet. But why you don't use the Matrox Meteor frame grabber. In my mind the MBone tools from LBL should play with it. > > SO: is anyone using a Linux box to transmit video to the MBone using available > hardware and an external video source (Quick Cam is not sifficient !) ? > If so, PLEASE let me know ! > > Dietrich Thie phone : +49 371 531-1532 fax : +49 371 531-1629 $HOME : Lungwitzer Str. 12, 09337 Hohenstein-Er./Germany phone : +49 3723 48506 | mobile +49 177 3331626 >> Und aus dem Chaos sprach eine Stimme: "Sei froh und laechle, denn es koennte schlimmer kommen ... " ... Und ich laechelte und war froh und es kam schlimmer ! From rem-conf-request@es.net Wed Feb 12 02:26:32 1997 Received: from chronos.synopsys.com by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Feb 1997 23:25:57 -0800 Received: from atropos.synopsys.com by chronos.synopsys.com with SMTP id AA23201 (5.65c/IDA-1.4.4 for ); Tue, 11 Feb 1997 23:25:50 -0800 Received: from jaxom.synopsys.com (jaxom.synopsys.com [146.225.66.114]) by atropos.synopsys.com (8.6.9/8.6.9) with ESMTP id XAA25182; Tue, 11 Feb 1997 23:25:49 -0800 From: Greg Kulosa Received: (greg@localhost) by jaxom.synopsys.com (8.7.4/8.6.5) id XAA04109; Tue, 11 Feb 1997 23:24:57 -0800 Message-Id: <199702120724.XAA04109@jaxom.synopsys.com> Subject: Re: Any *FIRST HAND* use of Linux Boxes to source MBone video ? To: mbone-seminars@cl.cam.ac.uk Date: Tue, 11 Feb 1997 23:24:57 -0800 (PST) Cc: mbone@isi.edu, rem-conf@es.net In-Reply-To: from "Piete Brooks" at Feb 11, 97 03:11:51 pm Content-Type: text > We have a very old and slow dec3000/300lx running osf1_3.2D with a J300 board > which we use to transmit our Security Seminars (using nv, as it won't work > unver vic) which we'd like to replace with a linux box and frame grabber. > > A member of the dept bought a Matrox Millenium so that they could source > video, but so far they've been unable to get it to work as Matrox will not > release the necessary info to write a Linux driver :-((( > > SO: is anyone using a Linux box to transmit video to the MBone using available > hardware and an external video source (Quick Cam is not sifficient !) ? > If so, PLEASE let me know ! I have used the QuickCAM with success. However, you say that it won't work for you. I am working on support for the "AITech AIGotcha" Parallel-port frame grabber. It claims to do "real-time" video, and costs ~$149 US. It probably won't be able to do 30 frames/second, but I don't need that. 5-8 frames/second or so is _plenty_ for me and the MBONE. I wrote an E-mail message to info@aitech.com, and they said they would be releasing a developers kit "in a month". When I receive that information, I will work on a driver. My main focus is to get "vic" support ASAP. -- Greg A. Kulosa | "The avalanche has already started, it is too Systems Administrator | late for the pebbles to vote." - Ambassador Kosh Synopsys, Inc. |___________________________________________________ greg@synopsys.com 700 E. Middlefield Rd, Mountain View, CA 94043 From rem-conf-request@es.net Wed Feb 12 04:59:12 1997 Received: from mail.gmd.de by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Feb 1997 01:57:31 -0800 Received: by mail.gmd.de id AA27107 (5.67b8/IDA-1.5 for rem-conf@es.net); Wed, 12 Feb 1997 10:56:55 +0100 Date: Wed, 12 Feb 1997 10:56:55 +0100 From: Hans Mayer Message-Id: <199702120956.AA27107@mail.gmd.de> To: hasty@rah.star-gate.com, jcole@precept.com Subject: Re: MPEG Support In MBONE Tools Cc: rem-conf@es.net, vic@ee.lbl.gov >>Also am curious if H263 video will likely be added as a supported video type >>to vic anytime soon? >Is there a publicly available H263 codec? My understanding is that H263 >is a propieratory format which if used in a public domain tool one >may have to pay royalties. The same goes for G.763 . There is a sample codec implementation available at telenor, the Norwegian Telecom Research Institute. I have it and am looking into vic to find a way to interface it (well, actually, at the moment I'm struggling with native ATM support :-( ). If someone else already has made some progress in either writing their own codec or interfaceing the telenor one I would be very interested. There should be no licensing fees required if you don't make a commercial product out of it. Hans From rem-conf-request@es.net Wed Feb 12 05:12:15 1997 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Feb 1997 02:11:42 -0800 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id CAA28997; Wed, 12 Feb 1997 02:11:28 -0800 (PST) Message-Id: <199702121011.CAA28997@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Greg Kulosa cc: mbone-seminars@cl.cam.ac.uk, mbone@isi.edu, rem-conf@es.net Subject: Re: Any *FIRST HAND* use of Linux Boxes to source MBone video ? In-reply-to: Your message of "Tue, 11 Feb 1997 23:24:57 PST." <199702120724.XAA04109@jaxom.synopsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Feb 1997 02:11:28 -0800 From: Amancio Hasty >From The Desk Of Greg Kulosa : > > It probably won't be able to do 30 frames/second, but I don't need that. > 5-8 frames/second or so is _plenty_ for me and the MBONE. Well, the price of fast frame grabbers are dropping for instance Hauppage's WinCast/Tv retails for about $149(US) . This is a PCI card with a Bt848 chipset and a tuner . I bought a CCD camera for about $200 from Computer Modules (http://www.compmod.com) . The camera has a builtin mic. So for about $349 you can have a fairly decent video subsystem. The fast video transfer comes in handy to watch TV 8) Enjoy, Amancio From rem-conf-request@es.net Wed Feb 12 14:28:18 1997 Received: from ANLCHM.CHM.ANL.GOV by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Feb 1997 11:27:24 -0800 Received: from anchm3 by ANLCHM.CHM.ANL.GOV with SMTP; Wed, 12 Feb 1997 13:25:38 -0600 (CST) Message-Id: <3.0.1.32.19970212132819.00949c40@anlchm.chm.anl.gov> X-Sender: clmarshall@anlchm.chm.anl.gov X-Mailer: Windows Eudora Pro Version 3.0.1 beta 13 (32) Date: Wed, 12 Feb 1997 13:28:19 -0600 To: rem-conf@es.net, mbone@anl.gov From: Chris Marshall Subject: Mbone Broadcast of Seminar Cc: mike_petrick@qmgate.anl.gov (Michael Petrick/ANL), klein@che.udel.edu (Michael Klein at U of Delaware), bertolac@che.udel.edu (Ralph Bertolacini/Amoco/retired) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" On Thursday, February 20, 1997 the Argonne Petroleum Seminar Series will broadcast the following seminar live. The broadcast will begin at 10:30 am CST. Visit the Argonne Petroleum Seminar Series web site at (http://www.anl.gov/Petroleum) for further information. Computer-Assisted Generation of Detailed Kinetic Models (ABSTRACT BELOW) Professor Michael T. Klein Department of Chemical Engineering University of Delaware Newark, Delaware 19716 ____________________________________________ As a preliminary test to this live broadcast we will be broadcasting two of the 1996 talks from 10 am to 2 pm on February 18 & 19, 1997. These talks are: RECENT AND FUTURE DEVELOPMENTS IN FLUIDIZED CATALYTIC CRACKING (FCC) Hartley Owen Sr. Engineering Consultant (retired) Mobil Research & Development Corp. THE IMPACT OF PRODUCT SPECIFICATIONS ON OIL REFINING William H. Keesom UOP Research Center ________________________________________________ Computer-Assisted Generation of Detailed Kinetic Models ABSTRACT The industrially relevant problem of kinetics assisted catalyst analysis and design motivated the development of a kinetic model generation technique with on-the-fly computational quantum chemistry calculations. This integrated system for the computer generation of kinetic models begins by modeling the structure of the reactants. Required reaction information includes the rules by which the reactant and product species react and the parameters of a structure/property kinetics correlation. This structural and reaction information is transformed into reactant/product relationships, i.e., the reaction mechanism, species properties, rate constants, and the FORTRAN or C code corresponding to the governing species balance equations. The advantage of computer generated reaction mechanisms is the enumeration of what can be thousands of elementary reactions and the strict accounting of what can be hundreds of species without the tedious manual effort that is prone to errors. A set of reactions has no quantitative value, however, without the associated rate parameters. The elementary reactions are therefore categorized in terms of reaction families, the reactivity within each reaction family being characterized in terms of a linear free energy relationship, e.g., Eq. (1). log ki = a + b RIi...........(1) The use of linear free energy relationships transforms the problem of estimating reaction rate constants into the problem of estimating the reactivity index (RI) for each reaction. The appropriate reactivity index might require estimation of a wide range of species properties, such as heat of reaction, electron affinity, electron density, proton affinity, etc. Computational quantum chemistry is a robust, growing technique for obtaining this information, and it is therefore interfaced directly with the reaction mechanism generator to accomplish the on-the-fly calculation of properties. This kinetic model building approach is illustrated using the topics of hydrocarbon catalysis, pyrolysis and oxidation. =============================================== Christopher L. Marshall, Research Scientist Chemistry Division/Coal Chemistry Group Argonne National Laboratory, CHM/200 9700 South Cass Avenue Argonne, IL 60439-4831 =============================================== E-mail: CLMARSHALL@ANL.GOV Phone: (630)252-4310 Fax: (630)252-9288 =============================================== Current Issues in Petroleum Processing Seminar Series at Argonne < http://www.anl.gov/Petroleum > 15th North American Catalysis Society Meeting, Chicago, 1997 < http://www.anl.gov/NAM > =============================================== From rem-conf-request@es.net Wed Feb 12 18:10:21 1997 Received: from chronos.synopsys.com by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Feb 1997 15:09:30 -0800 Received: from atropos.synopsys.com by chronos.synopsys.com with SMTP id AA02020 (5.65c/IDA-1.4.4 for ); Wed, 12 Feb 1997 15:09:13 -0800 Received: from jaxom.synopsys.com (jaxom.synopsys.com [146.225.66.114]) by atropos.synopsys.com (8.6.9/8.6.9) with ESMTP id PAA00914; Wed, 12 Feb 1997 15:09:11 -0800 From: Greg Kulosa Received: (greg@localhost) by jaxom.synopsys.com (8.7.4/8.6.5) id PAA06400; Wed, 12 Feb 1997 15:08:20 -0800 Message-Id: <199702122308.PAA06400@jaxom.synopsys.com> Subject: Re: Any *FIRST HAND* use of Linux Boxes to source MBone video ? To: hasty@rah.star-gate.com (Amancio Hasty) Date: Wed, 12 Feb 1997 15:08:20 -0800 (PST) Cc: greg@Synopsys.COM, mbone-seminars@cl.cam.ac.uk, mbone@isi.edu, rem-conf@es.net In-Reply-To: <199702121011.CAA28997@rah.star-gate.com> from "Amancio Hasty" at Feb 12, 97 02:11:28 am Content-Type: text > >From The Desk Of Greg Kulosa : > > > > It probably won't be able to do 30 frames/second, but I don't need that. > > 5-8 frames/second or so is _plenty_ for me and the MBONE. > > Well, the price of fast frame grabbers are dropping for instance > Hauppage's WinCast/Tv retails for about $149(US) . This is a PCI > card with a Bt848 chipset and a tuner . I should have mentioned that I am working on a Parallel-port frame grabber because I want to do MBONE from a laptop. There are no PCI slots on any laptop I have found :-) BTW, I also know that there is "vic" support for the "IBM PCMCIA Smart Capture Card", but I have been unable to find this device. It is not on IBM's web page. > Enjoy, > Amancio -- Greg A. Kulosa | "The avalanche has already started, it is too Systems Administrator | late for the pebbles to vote." - Ambassador Kosh Synopsys, Inc. |___________________________________________________ greg@synopsys.com 700 E. Middlefield Rd, Mountain View, CA 94043 From rem-conf-request@es.net Wed Feb 12 21:57:25 1997 Received: from mail.arc.nasa.gov (actually nick.arc.nasa.gov) by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Feb 1997 18:55:52 -0800 Received: from [128.102.80.28] by mail.arc.nasa.gov (8.8.5/1.35) id SAA05941; Wed, 12 Feb 1997 18:53:08 -0800 (PST) Date: Wed, 12 Feb 1997 18:53:08 -0800 (PST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 1 (Highest) To: rem-conf@es.net From: mallard@mail.arc.nasa.gov (Mark Allard) Subject: NASA-Shuttle Mission (STS-82) MBone Coverage Change Those currently logged into the separate video and audio sessions of "NASA-Shuttle Mission STS-82" MBone coverage need to disconnect from those sessions and reconnect to the "NASA-Shuttle Mission (Video/Audio) STS-82" combined session ASAP. This is required due to significant problems identified in some combined viewing tools and new integrated products that are having difficulty dealing with the separate streams. I would like to get specific EMail feedback from those who have difficulty running both video and audio simultaneously to better understand the extent of the issue, what the specific limitations are, and how we can best respond to these needs; send to . For those with limited connectivity desiring access to Shuttle mission video and audio, I might suggest, as an immediate alternative, the use of the CU-SeeMe reflector services provided by NASA; is a good site to try. Apologies for the inconvenience and confusion this has caused and hope you will enjoy the remainder of the Shuttle mission on our combined MBone session. M From rem-conf-request@es.net Thu Feb 13 00:54:41 1997 Received: from mgate2.uni-hannover.de by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Feb 1997 21:53:42 -0800 Received: from sun229a.rrzn-nis.uni-hannover.de (actually sun229a) by mgate2.uni-hannover.de with SMTP (PP); Thu, 13 Feb 1997 06:55:27 +0100 Received: by sun229a.rrzn-nis.uni-hannover.de (SMI-8.6/SMI-SVR4) id GAA01085; Thu, 13 Feb 1997 06:53:02 +0100 Message-Id: <199702130553.GAA01085@sun229a.rrzn-nis.uni-hannover.de> Subject: MBone/sdr-"phonebook" To: rem-conf@es.net Date: Thu, 13 Feb 1997 06:52:57 +0100 (MET) Reply-To: wsb@rrzn.uni-hannover.de From: wsb@rrzn.uni-hannover.de (Wolfgang Sander-Beuermann) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Hi! We have made an MBone/sdr-Directory-Service doing more than just a simple listing: http://meta.rrzn.uni-hannover.de/mbone.html A public directory service for Mbone/sdr users: every potential user can list her/himself here. The directory service checks automatically at several random times per 24 hours the sdr port. After an inactivity of more than 2 month the entry will be deleted. The entries can also be checked manually at any time for current sdr activity. In short words: some kind of "phonebook", which checks whether the phone is actually connected. Comments/Entries/etc. more than welcome, Wolfgang -- Wolfgang Sander-Beuermann Tel.: use email wsb@rrzn.uni-hannover.de WebAdmin, Univ. of Hannover, Germany http://www.uni-hannover.de/ ----> MetaGer, the Meta-Search Enginge for German search engines http://meta.rrzn.uni-hannover.de/ From rem-conf-request@es.net Thu Feb 13 07:57:51 1997 Received: from tel1.tte.vtt.fi by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Feb 1997 04:55:59 -0800 Received: from tte2049.tte.vtt.fi (tte2049.tte.vtt.fi [130.188.12.149]) by tel1.tte.vtt.fi (8.8.5/8.8.5) with SMTP id OAA13617 for ; Thu, 13 Feb 1997 14:55:47 +0200 (EET) Message-Id: <3.0.32.19970213145725.0075e738@tel1.tte.vtt.fi> X-Sender: lucenius@tel1.tte.vtt.fi X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 13 Feb 1997 14:57:46 +0200 To: rem-conf@es.net From: Jan Lucenius Subject: video overlay cards for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Which video overlay cards are there which supports Windows NT (please mention also which version(s) of NT) on the PC ? _________________________________________________________________________ _/ _/ _/ _/_/_ _/_/_ _/_/_/_/ Jan Lucenius _/ _/ _/ _/ _/ _/ phone +358 9 4566511 _/ _/ _/ _/_/ _/_/ _/_/_/ fax +358 9 4567013 _/ _/ _/ _ _/ _ _/ _/ VTT Information Technology _/_/_/_/ _/_/_/ _/_/ _/_/ _/_/_/_/ PB 1202, 02044 VTT, Finland www http://www.vtt.fi/tte/tte22/lucenius/ mailto:jan.lucenius@vtt.fi From rem-conf-request@es.net Thu Feb 13 11:23:45 1997 Received: from janus.3com.com by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Feb 1997 08:22:45 -0800 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.2) with ESMTP id IAA25117 for ; Thu, 13 Feb 1997 08:22:43 -0800 (PST) From: Vipin_Jain@3mail.3com.com Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by new-york.3com.com (8.8.2/8.8.2) with SMTP id IAA16356 for ; Thu, 13 Feb 1997 08:20:08 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v1.05 (274.9 11-27-1996)) id 8825643D.005A7A04 ; Thu, 13 Feb 1997 08:28:14 -0700 X-Lotus-FromDomain: 3COM To: rem-conf@es.net Message-ID: <8825643D.005A4050.00@hqoutbound.ops.3com.com> Date: Thu, 13 Feb 1997 08:26:07 -0700 Subject: unsubscribe Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii unsubscribe rem-conf From rem-conf-request@es.net Thu Feb 13 13:52:26 1997 Received: from mail.mel.aone.net.au by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Feb 1997 10:51:46 -0800 Received: from LOCALNAME ([204.253.76.113]) by mail.mel.aone.net.au (8.6.13/8.6.11) with SMTP id FAA13691 for ; Fri, 14 Feb 1997 05:51:39 +1100 Message-ID: <33038D55.3F9B@b022.aone.net.au> Date: Thu, 13 Feb 1997 13:53:25 -0800 From: Scott Phillips Reply-To: scottgp@b022.aone.net.au Organization: GSD Pty Ltd X-Mailer: Mozilla 3.0 (Win16; U) MIME-Version: 1.0 To: rem-conf@es.net Subject: Re: unsubscribe References: <8825643D.005A4050.00@hqoutbound.ops.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe rem-conf From rem-conf-request@es.net Thu Feb 13 14:29:32 1997 Received: from nobozo.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Feb 1997 11:28:30 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id LAA12822; Thu, 13 Feb 1997 11:28:31 -0800 Date: Thu, 13 Feb 1997 11:28:31 -0800 Message-Id: <199702131928.LAA12822@nobozo.CS.Berkeley.EDU> X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: 298-list@bmrc.Berkeley.EDU, rem-conf@es.net From: Jerrlyn Iwata Subject: Berkeley Multimedia & Graphics Seminar Berkeley Multimedia and Graphics Seminar (Wednesday February 19, 1997 12:30-2:00 PDT 405 Soda Hall) "EColabor: Collaborative Elaboration of Requirements Documents" Jeff Smith NTT Laboratories EColabor is an active hypermedia for collaboratively elaborating system requirements. EColabor is designed to address problems in communication, agreement, change management in requirements analysis, which are reportedly significant but rarely addressed. Based on the Inquiry Cycle model, EColabor supports analysts in systematically managing their requirements. EColabor records all the processes of elaborating requirements in shared hypermedia and provides comprehensive support for utilizing these records. Our goal is to apply multimedia and CSCW technologies to the requirements elicitation process. The main technical challenges with which we are faced are: (1) to establish feasible multimedia communication technology by using the Internet, (2) to integrate synchronous and asynchronous CSCW technologies, which have been independently developed, and (3) to develop a model and tools for multimedia note-taking. Conventionally, research on multimedia tends towards presentation. We emphasize support for authoring (or note-taking) multimedia information instead. The talk will provide a background on EColabor, report on the current status of the project, difficulties faced so far - including problems with MBONE/Internet multimedia, and future directions. ------------------------------------------------------------------------------- This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40 PDT (GMT - 8 hrs). See sdr or http://bmrc.berkeley.edu/298 for instructions on setting up, connecting to, and operating the MBONE tools. Please direct all technical questions to davesimp@cs.berkeley.edu From rem-conf-request@es.net Thu Feb 13 14:44:02 1997 Received: from relay4.smtp.psi.net by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Feb 1997 11:42:43 -0800 Received: from esh.vdo.net by relay4.smtp.psi.net (8.8.3/SMI-5.4-PSI) id OAA12424; Thu, 13 Feb 1997 14:42:36 -0500 (EST) Received: from vdo.net (root@wilder.vdo.net [206.233.3.10]) by esh.vdo.net (8.6.12/8.6.9) with ESMTP id LAA24078 for ; Thu, 13 Feb 1997 11:42:57 -0800 Received: from zelda.vdo.net ([206.233.3.122]) by vdo.net (8.6.12/8.6.9) with SMTP id LAA09547 for ; Thu, 13 Feb 1997 11:46:28 -0800 Received: by zelda.vdo.net with Microsoft Mail id <01BC19A3.1AC960A0@zelda.vdo.net>; Thu, 13 Feb 1997 11:43:17 -0800 Message-ID: <01BC19A3.1AC960A0@zelda.vdo.net> From: Oren Ariel To: 'IETF Mailing List' Date: Thu, 13 Feb 1997 11:43:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit unsubscribe rem-conf From rem-conf-request@es.net Thu Feb 13 15:35:49 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Feb 1997 12:34:43 -0800 Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id MAA06354; Thu, 13 Feb 1997 12:09:09 -0800 Date: Thu, 13 Feb 1997 12:10:31 -0800 () From: Stephen Casner To: Mark Allard cc: rem-conf@es.net Subject: Re: NASA-Shuttle Mission (STS-82) MBone Coverage Change In-Reply-To: Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 12 Feb 1997, Mark Allard wrote: > This is required due to significant problems identified in some combined > viewing tools and new integrated products that are having difficulty > dealing with the separate streams. Precept's IP/TV was an example, and we appreciate Mark's making the change to a combined session. I'd like to clarify a couple of points, though: IP/TV does _not_ require that the audio and video be sent to the same multicast address, as has been done in the new combined session announcement. sdr does allow separate addresses when both media are defined in one session (in fact this is the default). Using separate addresses is a good idea to allow sites on low-bandwidth links to tune in to only one of the media. The problem for us was that we don't have a way to tune in to separate audio and video sessions and synchronize them. Perhaps this is a feature we need to add if sessions are likely to be defined in multiple parts. -- Steve From rem-conf-request@es.net Thu Feb 13 16:34:22 1997 Received: from woody.multilink.com (actually multilink.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Feb 1997 13:33:10 -0800 Received: (from mail@localhost) by woody.multilink.com (8.6.12/8.7.3) id QAA12318 for ; Thu, 13 Feb 1997 16:38:12 -0500 From: Jim_Hirni@multilink.com Received: from multimail.multilink.com(172.16.7.3) by woody via smap (V1.3) id sma012310; Thu Feb 13 16:37:52 1997 Received: from cc:Mail by multimail.multilink.com id AA855881133; Thu, 13 Feb 97 16:28:00 PST Date: Thu, 13 Feb 97 16:28:00 PST Encoding: 1 Text Message-Id: <9701138558.AA855881133@multimail.multilink.com> To: rem-conf@es.net Subject: unsubscribe unsubscribe rem-conf From rem-conf-request@es.net Thu Feb 13 19:48:39 1997 Received: from mailhub.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Feb 1997 13:55:48 -0800 Received: from tao.fokus.gmd.de (tao [192.35.149.93]) by mailhub.fokus.gmd.de (8.8.3/8.8.3) with ESMTP id WAA04281 for ; Thu, 13 Feb 1997 22:55:28 +0100 (MET) From: Christian Zahl Received: (cz@localhost) by tao.fokus.gmd.de (SMI-8.6/8.6.12) id WAA04712 for rem-conf@es.net; Thu, 13 Feb 1997 22:55:20 +0100 Date: Thu, 13 Feb 1997 22:55:20 +0100 Message-Id: <199702132155.WAA04712@tao.fokus.gmd.de > X-Mailer: exmh version 1.6.1 5/23/95 To: Stephen Casner Cc: rem-conf@es.net Subject: Re: Inconsistence in IP/UDP/RTP compression ID In-reply-to: Your message of "Mon, 10 Feb 1997 20:29:13 PST." Mime-Version: 1.0 Content-Type: text/plain Stephen, first of all many thanks for the detaild answers you have given. > > We are currently developing a method for transfering multiple > > RTP streams over a low-bandwidth PPP connection. The implementaion > > consists of an RTP mixer on both ends of the PPP link, which > > adjust the payload-type field according to the bandwidth > > available. So it can happen very often, > > How often? It seems to me that the rate will need to be limited in > order to maintain stability (avoid oscillation). In particular, > changes in the direction of increasing the data rate should not be > done too quickly. How long an integration time is needed to measure > the available bandwidth? Considering those factors, how many packets > would be transmitted with one payload type before switching to > another, and for what size packets? Putting those numbers together, > then you could figure out the percentage overhead caused by the need > to send the full RTP header, including what your expected CSRC list > size would be, on a payload switch. If you have done this analysis, > please tell us about the numbers. Of course, the switch of the payload should not be made too often. Otherwise the coding related contexts as for GSM or LPC are totally out of date. I expected not to switch the PT more than once in about 30 seconds. So you're right, the overhead to send a full RTP header (12 bytes) instead of 2 (first 2 bytes) +1 (for the PT) bytes isn't worth to be mentioned! > > 2. CSRC change compression > > Well as described above we use a mixer and expect several sources for > > the outgoing media stream. The current ID says, that, when the CSRC > > list changes, then the whole list has to be transmitted. Because there > > are several sources and we can assume that they also change more > > frequenctly, I think that sending the whole list ist very poor! > > Do you expect to have several sources active at once? Part of the > motivation for the current CSRC design is the expectation that, for > example in the cause of mixing an audio conference, most of the time > there will be only one person talking so the CSRC list will contain > only that one identifier. Well I think this is theory. In pratice, most players will have silence detection enabled. So when you have a conference or seminar, and one or two interrupts the speaker, you will have several sources at the same time. Because of the silence detection, the packets will oscillate, and because of the delay, the orginal speaker notices this some time after. (Well I haven't meassured this, so this statement is also theory :-) > Now, your application might be quite different such that many sources > are transmitting at once. If so, would they stop and start > frequently, or would they be transmitting all the time such that the > CSRC list wouldn't change? In particular, would the number of packets > sent in whatever is equivalent to a "talkspurt" be small? If the > ... > > In the conferencing example I mentioned earlier, when one person stops > talking and another person starts talking, your proposal would require > a CSRC list with two entries whereas the current spec would require > only one. I expect this case to be pretty common for mixers. You're right I think. It was only an idea of mine, because while trying to implement the compression protocol, this question arrose. My problem is that I don't have so much experiences of how often the changes occurs. But in any way, 1) my mentioned protocol isn't very fine and stable, 2) the gain seems to be very low. So let's forget this idea! > > Hm, perhaps; I don't see any difference between "Data field" and > > "data field" ?! Anyway, because I'm not familar with IPv6, I didn't > > know what the "Data field" is. > > What I meant was, the IPv6 Header Compression spec defines a specific > field named "Data". Please note that the reference here is not to > IPv6, but to the IPv6 Header Compression spec. I understand, I haven't looked into the spec up to now, but your explaination helped me. (I think it would be good to also explain this in the ID?) > The ID is only a 16-bit number, so the delta can't be > 0x3fffff or > <0. Or, more precisely, any delta value can be encoded into 1 to 3 > bytes by the specified encoding table. Oh dear me, I'm an idiot, of course! %%$%&/!@# > That's unfortunate, although legal, I guess. Can the purveyors of > Linux be convinced to htonl() the IP ID field? Because of the mistake above, there is no need. BTW, W95 seems to do the same... > > Perhaps we should think about using negative values for the delta > > values? BTW, the same can theoretically happen when two IP packets > > arrive in the wrong order (packet N+1 first, then packet N). If this > > happens often, then the compression has NO gain! So how about of > > using INTs for the delta fields instead of UNSIGNEDs. Ok, this > > will reduce the maximum transferable delta value in one byte to > > +-63. If you think this is too less, then we can say: > > o the 1 byte form is UNSIGNED > > o the 2 and 3 byte forms are SIGNED > > At the IETF meeting, it was suggested that the delta encoding be > specified as a table rather than a function, with the default value of > the table being set according to the encoding currently in the spec. > (This is as a precursor to a future capability to download a new table > on a per-context basis for full entropy encoding.) Since there are > some holes in the current encoding, I suggest using those for negative > offsets. This keeps the encoding tuned for the common case of > positive offsets, but handles a portion of the negative offsets with > reasonable efficiency as well: > > Decimal Hex > > -16384 C0 00 00 > : : > -129 C0 3F 7F > -128 80 00 > : : > -1 80 7F > 0 00 > : : > 127 7F > 128 80 80 > : : > 16383 BF FF > 16384 C0 40 00 > : : > 4194303 FF FF FF > > Any delta < -16384 or > 4194303 would require a FULL_HEADER, > COMPRESSED_NON_TCP or COMPRESSED_UDP packet type. > > This encoding still leaves one hole of size 128 from C0 3F 80 to > C0 3F FF just to keep the logical (vs. arithmetic) relationship in the > table. We could get 128 more negative numbers by sliding down the > three-byte values instead. I don't know if that makes a significant > difference. (Should be none if the algorithm is table-driven.) > Comments, anyone? That's very interesting, I think. First, PLEASE mention in the ID that "7F" is different to "807F". In my prior understanding I assumed that both are the same (127) and that the first form is just some kind of "compression". I didn't undersood that the second form is a "whole" in the definition. Anyway, I think that using the holes for negative values is a very interesting aspect. Also the use of a downloadable table or an dynamical changing table is very interesting. When you think of an RTP stream comming from one sender, you can expect discrete values for the deltas. E.g. in most cases the deltas in the context changes only when a packet was lost (for audio). So when you can expect that the new delta is a multiple of the smallest delta in the context (i.e. RTP-ID = 1 and RTP-timestamp = #samples in frame, e.g. 320 for vat's PCM2), you only need those values. While listening to the NASA STS-82 session, I noticed that the packet loss (here in Germany) is often between 1 and 10. It also occurs that the packets gets out of order (i.e. negative timestamp). So we need only, let's say 20 *2 different deltas, which can be encoded in on octet, even if the delta (for the timestamp) is up to 3200 (320*10). So using a table sounds to be very efficient for me. > > Now sender A changes the payload-type. This forces the translator T to > > send the packet as COMPRESSED_UDP instead of COMPRESSED_RTP. There > > will arrive several questions: > > o to which context do the outgoing packet belongs, cA or cB? > .... > sources trade off. Or, you can use 16-bit context IDs as described in > the ipv6-hc draft (details to be added to the compressed RTP spec > soon). Thanks a lot for these very detailed informations! They helped me in understanding the real process and idea much better. > I'd appreciate any comments you might have on what additional > information I should add to the document and where. Ok, here are some comments: o fields like "Data" field should be explicitely explained on not only by reference to the IPv6 hc draft. o the holes should be explixit mentioned (see above). o the fact that the RTP fields also HAVE TO be saved for the COMPRESSED_UDP should be described a little bit better. Ok, after your comments and after rereading pages 4 and 5, it seems to be clear, but it wasn't before :-/ o I also think that it would be better to explicitly describe each "packet type" (FULL_HEADER, ...) in it's own section, and to describe what happens with which fields in the context. This will make the understanding much easier, I hope. One problem in the current ID is, that you have read (nearly) the whole ID to understand one part (that's only my opinion!) Anyway, it's an interesting ID and I'm happy to play with it :--) Once again, thanks a lot for your very detailed help you have given me. CU, Chris From rem-conf-request@es.net Fri Feb 14 01:32:26 1997 Received: from rcs1.urz.tu-dresden.de by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Feb 1997 22:31:34 -0800 Received: from rcs12.urz.tu-dresden.de by rcs1.urz.tu-dresden.de (8.6.12/SDL-5.7) with SMTP id HAA17100; Fri, 14 Feb 1997 07:31:20 +0100 Received: from localhost by rcs12.urz.tu-dresden.de (5.65v3.2/SDL-5.6) with SMTP id AA06265; Fri, 14 Feb 1997 07:31:18 +0100 Date: Fri, 14 Feb 1997 07:31:18 +0100 (MET) From: Rainer Kranz X-Sender: kranz@rcs12.urz.tu-dresden.de Reply-To: Rainer Kranz To: Amancio Hasty Cc: mbone-seminars@cl.cam.ac.uk, mbone@isi.edu, rem-conf@es.net Subject: Re: Any *FIRST HAND* use of Linux Boxes to source MBone video ? In-Reply-To: <199702121011.CAA28997@rah.star-gate.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE How can I use the WinCast/Tv in a Linux System ? Rainer ,-----------------------------------------------------------------. | Referenzzentrum f=FCr multimediale Teledienste (MMRZ), TU Dresden | | Dr. Klaus K=F6hler, Christoph Fleck, Rainer Kranz | | e-mail: mmt-ref@tu-dresden.de Tel.: 0351 / 463 5653 | | WWW: http://www-mm.urz.tu-dresden.de (GERMANY) | `-----------------------------------------------------------------' From rem-conf-request@es.net Fri Feb 14 02:38:06 1997 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Feb 1997 23:37:07 -0800 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id XAA20170; Thu, 13 Feb 1997 23:37:01 -0800 (PST) Message-Id: <199702140737.XAA20170@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Rainer Kranz cc: mbone-seminars@cl.cam.ac.uk, mbone@isi.edu, rem-conf@es.net Subject: Re: Any *FIRST HAND* use of Linux Boxes to source MBone video ? In-reply-to: Your message of "Fri, 14 Feb 1997 07:31:18 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Feb 1997 23:37:01 -0800 From: Amancio Hasty I have no idea ;however, if you are interested in porting the FreeBSD driver to linux I can provide the driver. Amancio >From The Desk Of Rainer Kranz : > > How can I use the WinCast/Tv in a Linux System ? > > Rainer > > ,-----------------------------------------------------------------. > | Referenzzentrum f=FCr multimediale Teledienste (MMRZ), TU Dresden | > | Dr. Klaus K=F6hler, Christoph Fleck, Rainer Kranz | > | e-mail: mmt-ref@tu-dresden.de Tel.: 0351 / 463 5653 | > | WWW: http://www-mm.urz.tu-dresden.de (GERMANY) | > `-----------------------------------------------------------------' > > > From rem-conf-request@es.net Fri Feb 14 06:25:39 1997 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Feb 1997 03:24:56 -0800 Received: from boom.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Feb 1997 11:14:01 +0000 X-Mailer: exmh version 1.6.6 3/24/96 To: rem-conf@es.net Cc: merci@cs.ucl.ac.uk Subject: MERCI Seminar Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Feb 1997 11:13:59 +0000 Message-ID: <12893.855918839@cs.ucl.ac.uk> From: Roy Bennett The MERCI (Multimedia European Research Conferencing Integration) project announces the next in an on-going series of seminars on subjects in the fields of Multimedia, Communications, Networks, Distributed Systems and CSCW Time : 18 February 14:00 UTC Title: Network Measurement on the Internet Chair: Peter Kirstein Speaker: Rob Cole HP Labs, Bristol, UK An announcement will be made in sdr later. The seminar has been booked in the MBone Session Agenda (http://www.cilea.it/MBone/browse.html). If there are still problems with overlap, please contact me. Roy ----------------------------------------------------------------------- Roy Bennett, Project Manager, MERCI http://www-mice.cs.ucl.ac.uk/merci/ Computer Science Phone: +44 171 380 7934 University College London Fax: +44 171 387 1397 Gower Street, LONDON WC1E 6BT Email: rbennett@cs.ucl.ac.uk ----------- http://www-dept.cs.ucl.ac.uk/staff/R.Bennett -------------- From rem-conf-request@es.net Sat Feb 15 03:07:16 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Sat, 15 Feb 1997 00:06:20 -0800 Received: from little-bear.precept.com by precept.com (SMI-8.6/SMI-SVR4) id AAA11845; Sat, 15 Feb 1997 00:05:45 -0800 Date: Sat, 15 Feb 1997 00:05:44 -0800 (PST) From: Stephen Casner To: Christian Zahl cc: rem-conf@es.net Subject: Re: Inconsistence in IP/UDP/RTP compression ID In-Reply-To: <199702132155.WAA04708@tao.fokus.gmd.de > Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Well I think this is theory. In pratice, most players will have > silence detection enabled. So when you have a conference or > seminar, and one or two interrupts the speaker, you will have several > sources at the same time. Because of the silence detection, the > packets will oscillate, and because of the delay, the orginal > speaker notices this some time after. Yes, there will be some periods of talk-over. But it should not be necessary to update the CSRC list on a packet-by-packet basis. When someone interrupts the speaker, there will be a period of several packets when there is sound from both sources at once. The CSRC list will need to be updated when the interruption starts and when it ends. If the first speaker stops upon hearing the interruption, and then perhaps starts again, there may be some oscillation, but it will be on the scale of units of seconds not packets. So there should be several packets transmitted to amortize each CSRC list update. > > That's unfortunate, although legal, I guess. Can the purveyors of > > Linux be convinced to htonl() the IP ID field? > > Because of the mistake above, there is no need. BTW, W95 seems to > do the same... Even more unfortunate. I use W95 (not necessarily by choice :-) but I had not noticed this. Even though the byte-swapped update can be accommodated by the delta encoding, it will take more bytes. It would be nice if this htonl() could be introduced. > That's very interesting, I think. First, PLEASE mention in the ID > that "7F" is different to "807F". In my prior understanding I assumed > that both are the same (127) and that the first form is just some > kind of "compression". I didn't undersood that the second form is a > "whole" in the definition. You are (or were) right. The spec as currently written does not include the encoding of the negative deltas. This is a new proposal as of the IETF meeting, and I need to update the draft to include it. > Ok, here are some comments: Thanks for your suggestions. -- Steve From rem-conf-request@es.net Sun Feb 16 21:24:53 1997 Received: from sirius.ctr.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Sun, 16 Feb 1997 18:24:03 -0800 Received: from sweetpea (sweetpea.ctr.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.8.5/8.6.4.287) with SMTP id VAA15501; Sun, 16 Feb 1997 21:24:00 -0500 (EST) Message-ID: <3307EBEB.527C@ctr.columbia.edu> Date: Sun, 16 Feb 1997 21:26:03 -0800 From: Andrew Campbell Reply-To: campbell@ctr.columbia.edu Organization: Ceter for Telecommunications Research, Columbia University X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: rem-conf@es.net CC: TANTAWI@watson.ibm.com, PARRY@watson.ibm.com, campbell@ctr.columbia.edu Subject: HPN'97 Advance Program + Registration Information Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit H P N ' 9 7 A D V A N C E P R O G R A M SEVENTH IFIP CONFERENCE ON HIGH PERFORMANCE NETWORKING (HPN'97) White Plains, New York, April 28-May 2, 1997 http://www.ctr.columbia.edu/hpn97 THE PROGRAM AT A GLANCE: Monday April 28, 1997 9:00 - 12:30 Tutorial A: Wireless ATM and Mobile Computing Upkar Varshney, Washburn University, USA 13:30 - 17:00 Tutorial B: Scheduling Algorithms for Integrated Services Networks Hui Zhang, Carnegie Mellon University, USA Tuesday April 29, 1997: 9:00 - 12:30 Tutorial C: The Next Generation Internet Protocol Suite Doug Montgomery, NIST, USA 13:30 - 17:00 Tutorial D: Protocol Support for End-to-End QoS Guarantees across the Internet Raj Yavatkar, Intel, USA Wednesday April 30, 1997: 8:45 - 9:45 Conference Opening and Keynote Session 9:45 - 10:45 Experience with Standards 11:15 - 12:30 Multicast Implementation Issues 12:30 - 13:30 Conference Luncheon 13:30 - 15:00 Experimental Results 15:30 - 17:00 Multimedia Traffic Thursday May 1, 1997: 9:00 - 10:30 Quality of Service 11:00 - 12:30 Fundamental Concepts 12:30 - 13:30 Conference Luncheon 13:30 - 15:00 Architectural Issues 15:30 - 16:45 Bandwidth Allocation 18:00 - 22:00 CONFERENCE BANQUET (Dinner Cruise around NYC) Friday May 2, 1997: 9:00 - 10:30 Invited Presentations: Use of HPNs 11:00 - 12:30 Panel Discussion: Trends and Future of HPNs For details of the full program and registration information, please visit http://www.ctr.columbia.edu/hpn97 From rem-conf-request@es.net Sun Feb 16 23:57:04 1997 Received: from enterprise.pulver.com by osi-west.es.net with ESnet SMTP (PP); Sun, 16 Feb 1997 20:56:11 -0800 Received: (from jeff@localhost) by enterprise.pulver.com (8.6.12/8.6.12) id XAA00499; Sun, 16 Feb 1997 23:56:02 -0500 Date: Sun, 16 Feb 1997 23:56:01 -0500 (EST) From: Jeff Pulver To: rem-conf@es.net cc: rhaber@von.com Subject: Spring '97 Voice on the Net: Advance Program + Registration Information In-Reply-To: <3307EBEB.527C@ctr.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII V O N' 9 7 A D V A N C E P R O G R A M Spring '97 Voice on the Net Conference Telecommunications and Streaming Media on the Net San Francisco, April 1-3, 1997 http://www.pulver.com/von97 THE PROGRAM AT A GLANCE: Tuesday April 1, 1997: 8:00 - 12:30 Keynotes / General Sessions (University of Pennslvania, Cisco, MCI, WorldCom, Intel, Netscape, elemedia) 13:45 - 15:45 Keynotes / General Sessions (Compaq, Lucent, Pacific Bell, IBM) 15:45 - 18:45 Breakout Sessions Wednesday April 2, 1997: 8:00 - 8:30 General Session - Standards Update (IMTC) 8:30 - 12:30 Breakout Sessions 13:45 - 14:45 Scott Adams (columnist Dilbert;Author the Dilbert Principle) 14:45 - 17:30 General Sessions (NTIA, MCI, AT&T, Sprint, Bell Atlantic) Thrusday April 3, 1997: 9:00 - 17:00 Internet Telephony Gateway Workshop For details of the full program and registration information, please visit- http://www.pulver.com/von97 From rem-conf-request@es.net Mon Feb 17 10:36:51 1997 Received: from monitor.internaut.com (actually Cust27.Max22.Seattle.WA.MS.UU.NET) by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Feb 1997 07:36:05 -0800 Received: from multi ([204.57.137.9]) by monitor.internaut.com (8.7.6/8.6.12) with SMTP id HAA05207; Mon, 17 Feb 1997 07:33:17 -0800 (PST) Received: by multi with Microsoft Mail id <01BC1CA4.AE913F20@multi>; Mon, 17 Feb 1997 07:32:08 -0800 Message-ID: <01BC1CA4.AE913F20@multi> From: Bernard Aboba To: "'mboned@ns.uoregon.edu'" Cc: "'rem-conf@es.net'" Subject: Multicast diagnostic tools I-D Date: Mon, 17 Feb 1997 07:32:05 -0800 Encoding: 53 TEXT For the Memphis IETF meeting, it would be useful to pull together an Internet Draft describing publicly distributable multicast diagnostic tools. The idea is to provide an overview of what tools are available and what problems they can be used to solve. Hope is that this will be a useful reference for those looking to deploy multicast on their networks. Assistance from tool authors and volunteers is solicited. I will act as editor. Information to be included on each tool: Author (name and e-mail address) Description (a paragraph or two describing what the tool does) Example (an example of the output of the tool) Applicability (domain of applicability i.e. uses SNMP, depends on DVMRP nearest neighbor, etc.) Availability (Platform availability, pointers to source and binary distributions) Tools that I'd like to include: Tools based on RTCP reports RTPmon RTPqual Tools based on SNMP mstat mconfig snmpoidget mrtree Tools based on DVMRP nearest neighbor messages mrdebug mrinfo mrmap map-mbone Tools based on IGMP mtrace mrbranch mbranch mcollect mlisten Network analysis tools mdump mpacket MVIEW AS mapping tools asn asname From rem-conf-request@es.net Tue Feb 18 02:31:12 1997 Received: from engr.orst.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Feb 1997 23:30:23 -0800 Received: from eel (eel.ENGR.ORST.EDU [128.193.55.69]) by engr.orst.edu (8.8.5/8.8.5) with SMTP id XAA25286; Mon, 17 Feb 1997 23:30:21 -0800 (PST) Received: from localhost by eel (SMI-8.6/ENGR-Client) id HAA10479; Tue, 18 Feb 1997 07:29:52 GMT Date: Mon, 17 Feb 1997 23:29:52 -0800 (PST) From: Stephane Chatre Reply-To: Stephane Chatre To: Henning Schulzrinne , rem-conf@es.net cc: Stephane Chatre Subject: rtptools' file format. In-Reply-To: <32F72B71.3818@cs.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi! As you probably noticed, several sites allowing playback on demand of recorded MBone sessions poped up here and there on the web, using for most of them rtpdump and rtpplay. IMHO, the file once dumped doesn't contain enough information regarding the content of the session: what is it about? When was it held and where? etc... I think this is time to decide for a standard format in which to record sessions, before it gets too much spread. I am thinking about adding a header which would be sort of a copy of the SDP packet used for the announcement of the session, because: - SDP was designed to contain almost all the informations needed about a session. - SDP info is easy to parse. - It would be easily applicable for recording a session in advance: a recorder could "listen" announcements and record interesting sessions, thus knowing the SDP content already. - On-demand Servers could Multicast SDP announcements of recordings available on a dedicated address/port, as well as the URL of "where" these sessions are available to playback. A drawback I see is that SDP packets contain information about all the streams of the session, which we not necessarly need to know about for a certain stream. But this might be useful, for example to know "part of which" the recorded stream was. If the session was not announced or the SDP packets were not received (session recorded on the fly), its fields could be left blank. Do you know if the IETF is working on defining a format for recorded sessions? If yes, has there been a draft about it? If not, what do you think? Best regards, Stephane. ======================== Stephane Chatre Email: chatre@cs.orst.edu Department of Computer Science Phone: (541) 737-5583 (office) Oregon State University (541) 757-3376 (home) Life is what happens to you while you're busy making other plans. - John Lennon From rem-conf-request@es.net Tue Feb 18 12:46:01 1997 Received: from magic (actually magic.ensica.fr) by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Feb 1997 09:45:09 -0800 Received: (from pdss@localhost) by magic (940816.SGI.8.6.9/8.6.12) id SAA11198 for rem-conf@es.net; Tue, 18 Feb 1997 18:31:30 +0100 Date: Tue, 18 Feb 1997 18:31:30 +0100 From: pierre de saqui sannes DFR/MI Message-Id: <199702181731.SAA11198@magic> To: rem-conf@es.net Subject: Workshop on Multimedia and Concurrency Please accept our apologies if you receive this email more than once. +++++++++++++++++++++++ CALL FOR PAPERS +++++++++++++++++++++++ FIRST INTERNATIONAL WORKSHOP ON MULTIMEDIA AND CONCURRENCY A Workshop within the XVIII International Conference on Applications and Theory of Petri Nets (June 23-27, 1997) Toulouse, June 24, 1997 Organizers : Michel Diaz, LAAS CNRS, Toulouse, France Thomas Little, Boston University, Boston, USA Patrick Senac, ENSICA, Toulouse, France Petri nets have been applied to the design of multimedia systems for a few years for different purposes : modeling, semantics, scheduling, resource allocation, protocols, etc. By multimedia systems it is meant general distributed systems that have new and complex constraints. Indeed distributed multimedia systems have to transfer and synchronise large volumes of data and to enforce strong time requirements on top of general Local area and Wide area networks. For instance, a remote multimedia presentation including one sequence of High Definition video, at a rate of 25 images per second, needs, only for this sequence, a time constrained flow of tens of megabits per second of transfert rate. This first workshop on this subject will be organized within the well-known conference "International Conference on Application and Theory of Petri nets". A set of papers plus one or two surveys will be presented. The scope of the workshop is focused on the application and theory of Petri nets applied to multimedia systems. Nevertheless, other models will be considered. Case studies describing applications will be welcome. Some topics are (not an exhaustive list): - modeling techniques (hierarchical, modular, high level, etc) - modeling time in multimedia information - performance evaluation and simulation - scheduling (off-line and real time) and optimization - time synchronisation and timed constraints - hypermedia reactive multimedia models - integration of different models of concurrency - user and user interaction modelling - PNs in Multimedia-Hypermedia communication protocols - PNs and the Web - applications and case studies Researchers interested are invited to submit a position paper (15 pages max, with a small abstract) or an extended abstract (some 5-8 pages) indicating the key ideas and results. The workshop will include time for presentations and discussions. IMPORTANT DATES ================ Submissions: Monday, March 31, 1997 * three hardcopies to: Michel Diaz LAAS-CNRS 7 Av. du Colonel Roche F-31077 Toulouse Cedex 4, FRANCE * or postscript files to the three following email address: diaz@laas.fr tdcl@BU.EDU senac@ensica.fr Notification of acceptance: May 5, 1997 Final copy of the paper, 15 pages, is due: May 30,1997 A proceedings of the papers will be given to the participants Pierre de Saqui-Sannes pdss@ensica.fr ENSICA 1 Place Emile Blouin tel. +33 5 61.61.86.81 31056 Toulouse Cedex fax. +33 5 61.61.86.86 From rem-conf-request@es.net Tue Feb 18 14:50:32 1997 Received: from nobozo.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Feb 1997 11:49:45 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id LAA30887 for ; Tue, 18 Feb 1997 11:49:24 -0800 Date: Tue, 18 Feb 1997 11:49:24 -0800 Message-Id: <199702181949.LAA30887@nobozo.CS.Berkeley.EDU> X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: Jerrlyn Iwata Subject: [Reminder] Berkeley Multimedia & Graphics Seminar Berkeley Multimedia and Graphics Seminar (Wednesday February 19, 1997 12:30-2:00 PDT 405 Soda Hall) "EColabor: Collaborative Elaboration of Requirements Documents" Jeff Smith NTT Laboratories MBONE BROADCAST BEGINS AT 12.40 PDT (GMT - 8 HOURS) From rem-conf-request@es.net Tue Feb 18 18:18:08 1997 Received: from venus.Sun.COM by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Feb 1997 15:17:00 -0800 Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA28283 for ; Tue, 18 Feb 1997 15:16:58 -0800 Received: from valathar.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA06621; Tue, 18 Feb 1997 15:16:55 -0800 Received: by valathar.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA04350; Tue, 18 Feb 1997 15:16:03 -0800 Date: Tue, 18 Feb 1997 15:16:03 -0800 From: Michael.Speer@Eng.Sun.COM (Michael F. Speer) Message-Id: <199702182316.PAA04350@valathar.eng.sun.com> To: rem-conf@es.net Subject: MBONE RTP session Cc: Michael.Speer@Eng.Sun.COM Folks: What happened to the "MBONE RTP Audio" session? It doesn't seem to announced anymore. Michael From rem-conf-request@es.net Tue Feb 18 19:10:33 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Feb 1997 16:09:23 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id QAA14616 for ; Tue, 18 Feb 1997 16:09:36 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma014554; Tue Feb 18 16:08:38 1997 Received: by hille.msri.org (8.7/MSRI) id QAA07298; Tue, 18 Feb 1997 16:07:56 -0800 (PST) Date: Tue, 18 Feb 1997 16:07:56 -0800 (PST) Message-Id: <199702190007.QAA07298@hille.msri.org> To: rem-conf@es.net From: m1 Reply-to: m1@msri.org Subject: Gil Kalai "Flag f-vectors of polytopes" MBone Broadcast Announcement ---------------------------- Title: Gil Kalai "Flag f-vectors of polytopes" Date: Feb 25, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/lecturenotes/97/kalai/ Description: Flag numbers of polytopes count chains of faces of prescribed dimensions. We will discuss what is known about them and especially the following: 1. The Bayer-Billera theorem on the affine dimension of flag numbers of $d$-polytopes, and various proofs and extensions of this theorem. 2. The notion of $h$-vector coming from intersection homology and its combinatorial significance for linear inequalities among flag numbers. 3. Combinatorial applications of the linear inequalities that were derived by Meisinger's program: FLAGTOOL. 4. A recent monotonicity theorem of Braden and MacPherson and some of the applications of the theorem and of the path to its proof. 5. The recent attempts by Jonathan Fine to extend the $h$ numbers into a complete set of invariants. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Feb 18 19:11:42 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Feb 1997 16:10:29 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id QAA14660 for ; Tue, 18 Feb 1997 16:10:41 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma014647; Tue Feb 18 16:10:20 1997 Received: by hille.msri.org (8.7/MSRI) id QAA07332; Tue, 18 Feb 1997 16:09:39 -0800 (PST) Date: Tue, 18 Feb 1997 16:09:39 -0800 (PST) Message-Id: <199702190009.QAA07332@hille.msri.org> To: rem-conf@es.net From: m1 Reply-to: m1@msri.org Subject: Bernd Sturmfels "The Geometry of A-graded Algebras" MBone Broadcast Announcement ---------------------------- Title: Bernd Sturmfels "The Geometry of A-graded Algebras" Date: Feb 26, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/lecturenotes/97/sturmfels/ Description: Let A be a configuration of n lattice vectors in d-space. An algebra over a field is called A-graded if it is graded by the semigroup spanned by A and each graded component is one-dimensional. This notion was introduced by V.I.Arnold who showed (jointly with Korkina and Post) that for d = 1, n < 4 and A fixed there are only finitely many isomorphism types of A-graded algebras, and they are indexed by the faces of the state polytope of A. Arnold's finiteness theorem is conjectured to hold for general d and n < d+4; this would extend Carl Lee's result that all triangulations of a d-polytope with d+3 vertices are regular. For n >= d+4 there are moduli of A-graded algebras, and the distinct algebra are parametrized by a binomial scheme which refines the Baues poset of all polyhedral subdivisions of A. This talk gives an introduction to this subject, along the lines of Chapter 10 in my book "Groebner Bases and Convex Polytopes". Emphasis will be placed on c! ! onnections to polytopes and integer programming. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Feb 18 19:13:56 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Feb 1997 16:12:31 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id QAA14707 for ; Tue, 18 Feb 1997 16:12:43 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma014697; Tue Feb 18 16:12:34 1997 Received: by hille.msri.org (8.7/MSRI) id QAA07368; Tue, 18 Feb 1997 16:11:52 -0800 (PST) Date: Tue, 18 Feb 1997 16:11:52 -0800 (PST) Message-Id: <199702190011.QAA07368@hille.msri.org> To: rem-conf@es.net From: m1 Reply-to: m1@msri.org Subject: Juergen Richter-Gebert "Moving and proving for configurations of points, lines, and conics" MBone Broadcast Announcement ---------------------------- Title: Juergen Richter-Gebert "Moving and proving for configurations of points, lines, and conics" Date: Feb 27, 1997 Time: 12:00 PST8PDT 1 hours Contact: m1@msri.org URL: http://www.msri.org/lecturenotes/97/richter-gebert/ Description: This talk illustrates the close interrelation of problems concerning
  • configuration spaces,
  • invariant theoretic methods for proving geometric theorems, and
  • the concrete implementation of interactive geometry software.
Here the influence of Abstract mathematics and concrete implementation work is bi-directional. On the one side interactive geometry programs can be used to explore Abstract geometric structures (like configuration spaces). Conversely, it often requires deep mathematical insights to implement interactive geometry programs that behave in a mathematical consistent way. The talk will be dedicated to an actual selection of interesting aspects of these interrelations. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Tue Feb 18 21:09:57 1997 Received: from proxy3.ba.best.com by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Feb 1997 18:08:08 -0800 Received: from mg134-058.ricochet.net (mg134-058.ricochet.net [204.179.134.58]) by proxy3.ba.best.com (8.8.5/8.8.3) with SMTP id SAA06914; Tue, 18 Feb 1997 18:00:49 -0800 (PST) Date: Tue, 18 Feb 1997 18:00:49 -0800 (PST) Message-Id: <1.5.4.16.19970218184641.475ff45e@pop.best.com> X-Sender: rsf@pop.best.com X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Stephane Chatre From: Ross Finlayson Subject: Re: rtptools' file format. Cc: rem-conf@es.net >I think this is time to decide for a standard format in which to record >sessions, before it gets too much spread. > >I am thinking about adding a header which would be sort of a copy of the >SDP packet used for the announcement of the session, because: >- SDP was designed to contain almost all the informations needed about a >session. >- SDP info is easy to parse. >- It would be easily applicable for recording a session in advance: a >recorder could "listen" announcements and record interesting sessions, >thus knowing the SDP content already. >- On-demand Servers could Multicast SDP announcements of recordings >available on a dedicated address/port, as well as the URL of "where" these >sessions are available to playback. Stephane, If you find that SDP contains all of the attributes that you need, then you should probably use it as-is. However, if there are additional attributes - not defined in SDP - that you need to represent, then you might consider something like MAFP (see http://www.lvn.com/multikit/mafp-list-info.html). MAFP can be thought of as a generalization of SDP that (among other things) allows an arbitrary set of attributes to be specified in a multicast-related announcement. Also, there is already a mapping defined (in code; not yet documented) from SDP to MAFP. Ross. From rem-conf-request@es.net Tue Feb 18 21:12:46 1997 Received: from all-purpose-gunk.near.net by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Feb 1997 18:11:22 -0800 Received: (from jhawk@localhost) by all-purpose-gunk.near.net (8.8.5/8.8.5) id VAA16484; Tue, 18 Feb 1997 21:11:18 -0500 (EST) From: John Hawkinson (local) Message-Id: <199702190211.VAA16484@all-purpose-gunk.near.net> Subject: Re: MBONE RTP session To: Michael.Speer@eng.sun.com (Michael F. Speer) Date: Tue, 18 Feb 1997 21:11:17 -0500 (EST) Cc: rem-conf@es.net In-Reply-To: <199702182316.PAA04350@valathar.eng.sun.com> from "Michael F. Speer" at Feb 18, 97 03:16:03 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > What happened to the "MBONE RTP Audio" session? It doesn't seem to announced > anymore. My workstation is still happily announcing it. It appears there's some issue with routing to me from you: [all-purpose-gunk!jhawk] ~> mtrace -g mbone.sun.com ap-gunk.near.net sap.mcast.net * Mtrace from 199.94.220.184 to 192.9.9.71 via group 224.2.127.254 Querying full reverse path... * switching to hop-by-hop: 0 mbone.Sun.COM (192.9.9.71) -1 * * * Timed out receiving responses [all-purpose-gunk!jhawk] ~> I suggest we take this up offline. Multicast in my neighborhood has been a bit more flakey than normal, though, so it may be somewhat local. --jhawk From rem-conf-request@es.net Wed Feb 19 15:16:29 1997 Received: from INET-04-IMC.microsoft.com (actually mail4.microsoft.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Feb 1997 12:15:38 -0800 Received: by INET-04-IMC.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC1E5E.DF3CBCB0@INET-04-IMC.microsoft.com>; Wed, 19 Feb 1997 12:17:28 -0800 Message-ID: From: Eric Fleischman To: "'rem-conf@es.net'" Subject: Problems with RTP Payload Types Date: Wed, 19 Feb 1997 12:13:37 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 59 TEXT This note addresses my concern that the payload type field of RTP (RFC 1889) is too small to accomplish its purpose over time. This note first examines our problem with dynamic payload type entries and extrapolates those problems to the general case. Table 2 in RFC 1890 defines the initial payload types for RTP. We are using the dynamic payload entries (values 96-127) of Table 2 in our current product. I have not noticed an official description of how this community desires these dynamic values to be used. Thus, I would appreciate pointers to the relevant documents, if any. What we are doing is using the dynamic values to specify specific codec and encoding values. Since our application has control over both the client and server "pieces" of the communication stream, we have arbitrarily defined that "Dynamic value x means codec Y at a specific sample size, sampling frequency and average bytes/sec." This, anyway, is how we have defined the meaning of "dynamic" -- subject to correction from this list. What we have found is that the 32 available dynamic payload values are inadequate for our needs. The problem which we are finding, and I suspect the industry as a whole can corroborate, is that a tremendous amount of work by a great many companies is going into defining new codecs and encoding/decoding approaches. Thus our product must necessarily support scads of codecs each with different possible sample sizes, sample frequencies, avg bytes/sec, etc. Users seem to demand the best quality encoding possible. Codec x may provide the best quality today but codec y may do so next week. Thus, we need a provision to keep adding new codecs with new encodings into our product. Thus, even if the 32 dynamic payload values were fully adequate for us today, it is only a matter of time before we run out of dynamic payload types that we can use within our application. Since the payload type (PT) field of RFC 1889 is only 7 bits long, the 128 available values thus are subject to the same problems. A glance at Table 2 of RFC 1890 shows that many of the listed codecs are now obsolete. Mind you, they are not obsolete in the sense that their specifications have somehow "gone away" or that those types are no longer used within some product somewhere. Rather, they are obsolete in the sense that their encoding quality is so poor that no "modern commercial product" would be willing to use them in the general case. Similarly, our product needs to maintain a certain number of "obsolete dynamic PTs" simply due to the versioning problem. My point is that it is impractical to "flush away" obsolete entries so that their place may be taken by more viable entries. If we assume all of today's most viable approaches will eventually become registered with IANA, it is improbable that there will be room to register some-future-date's most viable approaches if we assume that today's rapid codec development rate continues to persist over time. A solution scenario which expands the RTP header size to support a larger PT field would resolve this problem to an unspecified future time. But it would also increase the overhead of RTP. This would be very undesirable for slow modem rates which are very susceptible to such overheads. Please feel free to contact me if you are interested in discussing alternative solution scenarios. Yet before we initiate such a conversation, I'd first like to determine if the above observations resonate with this group as a whole or not. From rem-conf-request@es.net Wed Feb 19 16:11:15 1997 Received: from cs.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Feb 1997 13:10:23 -0800 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id QAA06416; Wed, 19 Feb 1997 16:10:17 -0500 (EST) Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id QAA15481; Wed, 19 Feb 1997 16:10:15 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <330B6C37.119@cs.columbia.edu> Date: Wed, 19 Feb 1997 16:10:15 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Eric Fleischman CC: rem-conf@es.net Subject: Re: Problems with RTP Payload Types References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dynamic is meant to mean that these values can be re-assigned on a (say) per-session basis, so unless you have more than 32 truly different codecs (not just a 16 kb/s version and a 32 kb/s version of the same video format, i.e., decodable with the same codec) active during the same session, this should not be a problem. Unfortunately, except for the case of session announcements with a limited set of pre-assigned codecs, there is no generally accepted way of negotiating the list of encodings of interest to the receiver. One might imagine a protocol where the client indicates to the server the list of codecs it understands/prefers and then have the server set up dynamic PTs for that list (which, within each stream, should be easily manageable with 32). SIP has facilities for things along this line. If there are codecs which are closely related (e.g., same codec, but different sample rate or channel count or bit depth or image size), the appropriate approach is to define the class an an RTP PT and define the specific subclass as part of the payload-specific encapsulation, unless you are so bit-constrained that this is not feasible. So, is it likely that a single server for a single media type (audio or video, say) will need to support 32 different encoding classes? Henning -- Henning Schulzrinne email: schulzrinne@cs.columbia.edu Dept. of Computer Science phone: +1 212 939-7042 Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs From rem-conf-request@es.net Wed Feb 19 16:14:35 1997 Received: from sirius.ctr.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Feb 1997 13:13:51 -0800 Received: from orion (orion.ctr.columbia.edu [128.59.68.28]) by sirius.ctr.columbia.edu (8.8.5/8.6.4.287) with SMTP id QAA20652; Wed, 19 Feb 1997 16:13:44 -0500 (EST) Sender: liao@ctr.columbia.edu Message-ID: <330B6D07.3ED4@ctr.columbia.edu> Date: Wed, 19 Feb 1997 16:13:43 -0500 From: Raymond Liao Organization: CTR, Columbia University X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: rem-conf@es.net CC: mnl@ctr.columbia.edu Subject: Seminar: C. Huitema "The Internet Architecture - End-to-End Principle" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MBone Broadcast Announcement Title: The Internet Architecture - End to End Principle Speaker: Christian Huitema Bellcore Date: Thursday, Feb. 20, 1997 Time: 12:00 PM - 1:00 PM EST Multicast Address: audio: DVI, RTP, 224.2.243.158/30528/127 video: H.261, RTP, 224.2.154.154/59442/127 Contact: Andrew T. Campbell (campbell@ctr.columbia.edu) URL: http://comet.ctr.columbia.edu/activities/seminars/ Place: Multimedia Network Laboratory 8LE1 Schapiro Research Building Center for Telecommunications Research Columbia University New York City, USA -- Raymond R.-F. Liao (212) 939-7158 http://www.ctr.columbia.edu/~liao Center for Telecommunications Research, Columbia University From rem-conf-request@es.net Wed Feb 19 17:10:30 1997 Received: from INET-04-IMC.microsoft.com (actually mail4.microsoft.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Feb 1997 14:09:40 -0800 Received: by INET-04-IMC.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC1E6E.B526DC70@INET-04-IMC.microsoft.com>; Wed, 19 Feb 1997 14:10:49 -0800 Message-ID: From: Eric Fleischman To: 'Henning Schulzrinne' Cc: "'rem-conf@es.net'" Subject: RE: Problems with RTP Payload Types Date: Wed, 19 Feb 1997 14:05:53 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 78 TEXT Thank you, Henning, for your very helpful reply. You pointed out some ideas which I hadn't considered which very likely may end my concern about dynamic PTs. If not, I'll get back to you once I have thought more about how things work if done the way you intended. Now I will try to answer your question: I have not encountered a real-life situation where a server needs to support 32 different encoding classes for a single media type when sub-classes are in use. Because the PT contains both audio and video entries, I originally imagined that both spaces had to be satisfied within that same PT class space and in that case the 32 limitation is a problem (see below). We also support several other media types in addition to audio and video. Thus, the problem which I envisioned was the following 1) our particular content may or may not be pre-announced via SIP or a similar capability. If it is pre-announced then we can benefit from the PT values being constrained to the values indicated within the announcement as you indicated. If it is not pre-announced, but rather initiated in an "on demand" fashion by user(s), then the PT values need to have already been agreed to by the sender-receiver and thus should include all of the encodings currently supported on that server. An example of "on-demand" use is when one or more users request that a pre-produced multimedia production be streamed to them. 2) In the "on demand" case, the total number of needed PT values definitely exceeds 32 if we lump all of the encodings for all of the supported media types on that server. If we segregate the encodings by media type and use your sub-class delineations, then 32 PT values should work for us today. Unfortunately, I can't speak for the future (as indicated by my original message) because the future may entail different codec innovation rates than today. If the rate of innovation increases, then we may or may not have a problem. Another relevant factor is how persistent the "older encodings" remain. (If they don't disappear then they take up space.) In any case, I can easily imagine the non-dynamic PT values quickly filling up with entries with an unknown shelf life viability. Thus I suspect that long-term only dynamic PT values will remain viable. It is thus desirable that we address how these dynamic values can best be used in "on-demand" scenarios. -----Original Message----- From: Henning Schulzrinne [SMTP:schulzrinne@cs.columbia.edu] Sent: Wednesday, February 19, 1997 1:10 PM To: Eric Fleischman Cc: rem-conf@es.net Subject: Re: Problems with RTP Payload Types Dynamic is meant to mean that these values can be re-assigned on a (say) per-session basis, so unless you have more than 32 truly different codecs (not just a 16 kb/s version and a 32 kb/s version of the same video format, i.e., decodable with the same codec) active during the same session, this should not be a problem. Unfortunately, except for the case of session announcements with a limited set of pre-assigned codecs, there is no generally accepted way of negotiating the list of encodings of interest to the receiver. One might imagine a protocol where the client indicates to the server the list of codecs it understands/prefers and then have the server set up dynamic PTs for that list (which, within each stream, should be easily manageable with 32). SIP has facilities for things along this line. If there are codecs which are closely related (e.g., same codec, but different sample rate or channel count or bit depth or image size), the appropriate approach is to define the class an an RTP PT and define the specific subclass as part of the payload-specific encapsulation, unless you are so bit-constrained that this is not feasible. So, is it likely that a single server for a single media type (audio or video, say) will need to support 32 different encoding classes? Henning -- Henning Schulzrinne email: schulzrinne@cs.columbia.edu Dept. of Computer Science phone: +1 212 939-7042 Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs From rem-conf-request@es.net Wed Feb 19 18:45:38 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Feb 1997 15:43:47 -0800 Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id PAA21367; Wed, 19 Feb 1997 15:24:56 -0800 Date: Wed, 19 Feb 1997 15:27:05 -0800 () From: Stephen Casner To: Eric Fleischman cc: "'rem-conf@es.net'" Subject: Re: Problems with RTP Payload Types In-Reply-To: Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Eric, > What we are doing is using the dynamic values to specify specific codec and > encoding values. Since our application has control over both the client and > server "pieces" of the communication stream, we have arbitrarily defined > that "Dynamic value x means codec Y at a specific sample size, sampling > frequency and average bytes/sec." This, anyway, is how we have defined the > meaning of "dynamic" -- subject to correction from this list. The root of the problem is that you have interpreted "dynamic" as "private". The point of dynamic payload types is that a given number will indicate a different encoding in different sessions. The mapping for a given session is specified outside RTP; for example, SDP defines a means to specify RTP dynamic payload type mappings. The allocation of a space of 32 type codes was based on the assumption that in a given session no more than 32 distinct encodings would be needed. -- Steve From rem-conf-request@es.net Wed Feb 19 18:55:23 1997 Received: from cs.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Feb 1997 15:54:24 -0800 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id SAA11520; Wed, 19 Feb 1997 18:54:18 -0500 (EST) Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id SAA15712; Wed, 19 Feb 1997 18:54:13 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <330B92A5.5FC0@cs.columbia.edu> Date: Wed, 19 Feb 1997 18:54:13 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Eric Fleischman CC: "'rem-conf@es.net'" Subject: Re: Problems with RTP Payload Types References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric Fleischman wrote: > > It is thus desirable > that we address how these dynamic values can best be used in "on-demand" > scenarios. That's where RTSP comes in. Clearly, RTSP can use SDP or other session description formats, so the server can advertise only those media types *for each stream* that are actually supported at any given time and assign the minimal set of PTs for those, without the client having to "remember" any of them. --- Henning Schulzrinne email: schulzrinne@cs.columbia.edu Dept. of Computer Science phone: +1 212 939-7042 Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs From rem-conf-request@es.net Wed Feb 19 20:45:06 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Feb 1997 17:43:54 -0800 Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id RAA21962; Wed, 19 Feb 1997 17:37:53 -0800 Date: Wed, 19 Feb 1997 17:40:02 -0800 () From: Stephen Casner To: Eric Fleischman cc: 'Henning Schulzrinne' , "'rem-conf@es.net'" Subject: RE: Problems with RTP Payload Types In-Reply-To: Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Because the PT contains both audio and video entries, I originally imagined > that both spaces had to be satisfied within that same PT class space No, the dynamic PT space is separate for each RTP session. In addition to the spaces being separate for audio and video sessions, a multimedia session which defined, for example, three audio RTP sessions could use different dynamic PT assignments for each of the audio sessions. > 1) our particular content may or may not be pre-announced via SIP or a > similar capability. If it is pre-announced then we can benefit from the PT > values being constrained to the values indicated within the announcement as > you indicated. If it is not pre-announced, but rather initiated in an "on > demand" fashion by user(s), then the PT values need to have already been > agreed to by the sender-receiver and thus should include all of the > encodings currently supported on that server. An example of "on-demand" use > is when one or more users request that a pre-produced multimedia production > be streamed to them. It is likely that there is some information that needs to be communicated between the server and client if you are going to use RTP. At a minimum, the port numbers to be used. You should be able to communicate the PT mapping along with the other info. If the server supports multiple encodings, then there may even have been a negotiation between client and server. As Henning mentioned, RTSP is applicable here. > Unfortunately, I can't speak for the future (as indicated by my original > message) because the future may entail different codec innovation rates > than today. If the rate of innovation increases, then we may or may not > have a problem. Another relevant factor is how persistent the "older > encodings" remain. (If they don't disappear then they take up space.) In > any case, I can easily imagine the non-dynamic PT values quickly filling up > with entries with an unknown shelf life viability. Thus I suspect that > long-term only dynamic PT values will remain viable. It is thus desirable > that we address how these dynamic values can best be used in "on-demand" > scenarios. It is essential that the dynamic PT values remain dynamic, or as you say, we will run out. It is just like we are now realizing with IP addresses. So, this has to be per session so it is independent of innovation rate. Regarding the non-dynamic part of the space, it seems likely that many new codecs will be used only with dynamic payload types throughout their lifetime. Perhaps only (a subset of) those standardized by the ITU will get static PT assignments. -- Steve From rem-conf-request@es.net Wed Feb 19 23:36:41 1997 Received: from wizard.gsfc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Feb 1997 20:35:54 -0800 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA25163; Wed, 19 Feb 97 23:35:40 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9702200435.AA25163@wizard.gsfc.nasa.gov> Subject: Re: MBONE RTP session To: ljhawk@bbnplanet.com (John Hawkinson) Date: Wed, 19 Feb 1997 23:35:39 -0500 (EST) Cc: Michael.Speer@eng.sun.com, rem-conf@es.net, bill@wizard.gsfc.nasa.gov (Bill Fink) In-Reply-To: <199702190211.VAA16484@all-purpose-gunk.near.net> from "John Hawkinson" at Feb 18, 97 09:11:17 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2422 > > What happened to the "MBONE RTP Audio" session? It doesn't seem to announced > > anymore. > > My workstation is still happily announcing it. > > --jhawk I also no longer see the "MBONE RTP Audio" session. -Bill wizard# mtrace ap-gunk.near.net sap.mcast.net Mtrace from 199.94.220.184 to 128.183.115.17 via group 224.2.127.254 Querying full reverse path... * switching to hop-by-hop: 0 wizard.gsfc.nasa.gov (128.183.115.17) -1 rtr-sno-e1.gsfc.nasa.gov (128.183.115.1) DVMRP thresh^ 0 -2 mbone2-f.gsfc.nasa.gov (128.183.242.17) DVMRP thresh^ 16 -3 * * mbone-cf.gsfc.nasa.gov (128.183.251.129) DVMRP thresh^ 16 -4 * * mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 32 -5 sanjose1-mbone1.bbnplanet.net (4.0.0.34) PIM/Special thresh^ 0 -6 paloalto-mbone1.bbnplanet.net (131.119.0.197) PIM/Special thresh^ 32 -7 collegepk-mbone1.bbnplanet.net (128.167.252.196) PIM/Special thresh^ 64 -8 cambridge1-mbone1.bbnplanet.net (199.94.207.2) PIM/Special thresh^ 32 -9 * * * * frobozz-magic-robot-e6-5.bbnplanet.com (192.52.71.34) didn't respond -10 * * * -11 * * * -12 * * * ...giving up Round trip time 196 ms; total ttl of 66 required. Results after 39 seconds: Source Response Dest Overall Packet Statistics For Traffic From * * * 224.0.1.32 Packet 199.94.220.184 To 224.2.127.254 v __/ rtt 215 ms Rate Lost/Sent = Pct Rate 199.94.207.2 cambridge1-mbone1.bbnplanet.net v ^ ttl 33 0/0 = --% 0 pps 128.167.252.196 collegepk-mbone1.bbnplanet.net v ^ ttl 66 0/0 = --% 0 pps 131.119.0.197 paloalto-mbone1.bbnplanet.net v ^ ttl 66 0/0 = --% 0 pps 4.0.0.34 sanjose1-mbone1.bbnplanet.net v ^ ttl 66 v 51 pps 0/0 = --% 0 pps 192.203.230.241 mbone.nsi.nasa.gov v ^ ttl 66 164 pps 0/0 = --% 0 pps 128.183.251.129 mbone-cf.gsfc.nasa.gov v ^ ttl 66 105 pps 0/0 = --% 0 pps 128.183.242.17 mbone2-f.gsfc.nasa.gov v ^ ttl 66 5 pps 0/0 = --% 0 pps 128.183.251.28 128.183.115.1 rtr-sno-e1.gsfc.nasa.gov v \__ ttl 66 0 pps 128.183.115.17 128.183.115.17 Receiver Query Source From rem-conf-request@es.net Thu Feb 20 11:27:50 1997 Received: from all-purpose-gunk.near.net by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Feb 1997 08:27:10 -0800 Received: (from jhawk@localhost) by all-purpose-gunk.near.net (8.8.5/8.8.5) id LAA26181; Thu, 20 Feb 1997 11:27:07 -0500 (EST) Date: Thu, 20 Feb 1997 11:27:07 -0500 (EST) Message-Id: <199702201627.LAA26181@all-purpose-gunk.near.net> To: rem-conf@es.net Subject: Re: MBONE RTP session From: John Hawkinson So, in case anyone cares, it turns out there was indeed something broken in my local topology (in addition to whatever confusion caused mtraces from Sun to myself to break) resulting in the MBone RTP Audio announcement failing to get out. That's been fixed, sorry for any confusion. --jhawk From rem-conf-request@es.net Thu Feb 20 12:10:31 1997 Received: from FNAL.FNAL.Gov by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Feb 1997 09:09:50 -0800 Received: from gungnir.fnal.gov ("port 33380"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IFMXQEYC1C001WLE@FNAL.FNAL.GOV>; Thu, 20 Feb 1997 11:09:40 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id LAA08584; Thu, 20 Feb 1997 11:09:39 -0600 Date: Thu, 20 Feb 1997 11:09:39 -0600 From: Matt Crawford Subject: Re: Seminar: C. Huitema "The Internet Architecture - End-to-End Principle" In-reply-to: "19 Feb 1997 16:13:43 EST." <"330B6D07.3ED4"@ctr.columbia.edu> Sender: crawdad@gungnir.fnal.gov To: Raymond Liao Cc: rem-conf@es.net, mnl@ctr.columbia.edu, campbell@ctr.columbia.edu Message-id: <199702201709.LAA08584@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Multicast Address: > audio: DVI, RTP, 224.2.243.158/30528/127 > video: H.261, RTP, 224.2.154.154/59442/127 From rem-conf-request@es.net Thu Feb 20 14:46:31 1997 Received: from cs.nps.navy.mil by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Feb 1997 11:45:09 -0800 Received: from grant.cs.nps.navy.mil by cs.nps.navy.mil (4.1/SMI-4.1) id AA13421; Thu, 20 Feb 97 11:44:57 PST Received: by grant.cs.nps.navy.mil (950413.SGI.8.6.12) id LAA22244; Thu, 20 Feb 1997 11:44:56 -0800 From: Michael mcCarthy Message-Id: <9702201144.ZM22242@grant.cs.nps.navy.mil> Date: Thu, 20 Feb 1997 11:44:56 -0800 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: rem-conf@es.net Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19702201144.ZM22242.cs.nps.navy.mil" --PART-BOUNDARY=.19702201144.ZM22242.cs.nps.navy.mil X-Zm-Content-Name: vrml Content-Description: Text Content-Type: text/plain ; name="vrml" ; charset=us-ascii MBone Broadcast Announcement ------------------------------- VIRTUAL REALITY MODELING LANGUAGE (VRML) SYMPOSIUM Monterey, California, February 24-26, 1997 http://www.sdsc.edu/vrml97/ The Second Annual Virtual Reality Modeling Language (VRML) Symposium is scheduled for February 24-26, 1997 at the Hyatt Regency in Monterey, California. VRML97 is an academic and technical symposium sponsored by ACM SIGGRAPH and SIGCOMM, in cooperation with the VRML Consortium. This year's VRML Symposium provides a wide range of technical papers, educational opportunities, cutting-edge demonstrations and exhibits featuring the latest in VRML technology. The VRML Symposium home page is http://www.sdsc.edu/vrml97 400-500 attendees from across the globe are expected to attend this powerful 3-day technical symposium. Attendees can attend half-day or full-day tutorials, which are designed for both intermediate and advanced VRML users and developers. The Symposium also includes working groups, panels, academic papers and in-depth exhibitor demonstrations. Topics include 3D graphics, content, behaviors, interfaces, modeling, simulation, multi-user environments, networking and standards. The Hyatt Regency Monterey is headquarters hotel for VRML 97. For registration info, please refer to the VRML 97 home page http://www.sdsc.edu/vrml97/register.html or contact Lynn Johnson at 408-655-9924 or ljohnson@redshift.com. MBone production comments to vrlm97@cs.nps.navy.mil, scheduling conflicts to mccarthy@cs.nps.navy.mil Symposium MBone Broadcast Schedule: (Demo SIG, papers and panels to be broacasted live via Mbone) Monday, February 24, 1997 5:00 PM Demo SIG at the Hyatt Regency Ballroom - Timothy Childs (Sponsored by VeRGe and Microsoft) Tuesday, February 25, 1997 8:30 AM Papers: Implementation I, Val Watson session chair Using spatial techniques to decrease message passing in a distributed VE system, Olof Hagsand, Rodger Lea and Marten Stenius, Swedish Institute of Computer Science (SICS) and Sony Computer Science Lab An Object Oriented Approach to VRML Development, Curtis A. Beeson, Silicon Graphics Inc. Object-Oriented VRML for Multi-user Environments, Sungwoo Park 10:00 AM Break 10:00 AM Exhibits open 10:30 AM Papers: Multi-user, Dave Nadeau session chair Populating the Internet: Supporting Multiple Users and Shared Applications with VRML, Wolfgang Broll, German National Institute for Information Technology Community Place: architecture and performance, Rodger Lea, Yasuaki Honda, Kouichi Matsuda and Satoru Matsuda, Sony Computer Science Lab SpaceFusion: A multi-server architecture for shared virtual environments, Hiroyasu Sugano, Fujitsu 12:00 PM VRML Consortium Report: Elected VRML Consortium Inc. Board of Directors 2:00 PM Papers: Navigation and User Interface, Dave Kerlick session chair QOTA: A Fast, Multi-Purpose Algorithm For Terrain Following in Virtual Environments, John W. Barrus and Richard Waters, Mitsubishi Electric Research Laboratory MaPS: Movement and Planning Support for Navigation in an Immersive VRML Browser, John Edwards and Chris Hand, De Montfort University, Leicester UK Adapting VRML 2.0 for Immersive Use, Randy Stiles, Sandeep Tewari and Mihir Mehta, Lockheed Martin Advanced Technology Center 3:30 PM Break 4:00 PM Panel: Avatar and Multi-user Standards, Moderator Bernie Roehl - University of Waterloo, Mitra - ParaGraph, David Anderson - MERL, Yasuaki Honda - Sony Computer Science Lab 5:00 PM Panel: Using Java as a VRML development platform, Moderator: Jeff Close, Chris Marrin - SGI, Chris Laurel - Dimension X, John DeCuir - Sony Computer Research Laboratory 6:00 PM Break Wednesday, February 26, 1997 8:30 AM Plenary speaker: Tony Parisi, Intervista 9:00 AM Working group and workshop reports 10:00 AM Break 10:00 AM Exhibits open 10:30 AM Papers: Case Studies, Tamara Munzner session chair The Out of Box Experience: Lessons learned creating compelling VRML 2.0 content,Sam Chen, Rob Myers and Rick Pasetto, Silicon Graphics Inc. Networked VR System: Kitchen Layout Design for Customers, Tomohiro Fukuda, Ryuichiro Nagahama and Junji Nomura, Matsusita Electric Works Ltd. Animation for Performance Debugging of Parallel Computing Systems, Noritaka Osawa, Hisaya Morita and Toshitsugu Yuba, The University of Electro-Communications, Japan Using VRML to Access Manufacturing Data, Sandy Ressler, Qiming Wang, Scott Bodarky, Charles Sheppard and Gregory Seidman, National Institute of Standards and Technology 2:00 PM Papers: Implementation II, Dick Puk moderator V-COLLIDE: Accelerated Collision Detection for VRML, Tom Hudson, Ming C. Lin, Jon Cohen, Stefan Gottschalk and Dinesh Manocha, University of North Carolina Lodestar: An Octree-Based Level of Detail Generator for VRML, Dieter Schmalstieg, Vienna University of Technology, Austria Wired for Speed: Efficient Routes for VRML 2.0, Daniel Woods, Alan Norton and Gavin Bell, Silicon Graphics Inc. and Wazabi 3:00 PM Exhibits close, tear down 3:30 PM Break 4:00 PM Panel: Expanding Cyberspace: Persistence, Scalability, and Security in VRML, Moderator: Tony Parisi - Intervista Software, Clay Graham - tinySystems, Dan Lipkin - Oracle, Bob Rockwell - Black Sun Interactive 5:00 PM Panel: User Interface Design for Digital Space: 3d Navigation and Manipulation, Moderator: Bernie Roehl - University of Waterloo, Maclen Marvit - Worlds Inc., James Waldrop - Construct, Mark Pesce - Author 6:00 PM Symposium complete --PART-BOUNDARY=.19702201144.ZM22242.cs.nps.navy.mil-- From rem-conf-request@es.net Thu Feb 20 14:47:58 1997 Received: from cs.nps.navy.mil by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Feb 1997 11:47:01 -0800 Received: from grant.cs.nps.navy.mil by cs.nps.navy.mil (4.1/SMI-4.1) id AA13462; Thu, 20 Feb 97 11:46:52 PST Received: by grant.cs.nps.navy.mil (950413.SGI.8.6.12) id LAA22261; Thu, 20 Feb 1997 11:46:47 -0800 From: Michael mcCarthy Message-Id: <9702201146.ZM22259@grant.cs.nps.navy.mil> Date: Thu, 20 Feb 1997 11:46:47 -0800 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: rem-conf@es.net Subject: VRML 97 MBone Broadcast Announcement Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19702201146.ZM22259.cs.nps.navy.mil" --PART-BOUNDARY=.19702201146.ZM22259.cs.nps.navy.mil X-Zm-Content-Name: vrml Content-Description: Text Content-Type: text/plain ; name="vrml" ; charset=us-ascii MBone Broadcast Announcement ------------------------------- VIRTUAL REALITY MODELING LANGUAGE (VRML) SYMPOSIUM Monterey, California, February 24-26, 1997 http://www.sdsc.edu/vrml97/ The Second Annual Virtual Reality Modeling Language (VRML) Symposium is scheduled for February 24-26, 1997 at the Hyatt Regency in Monterey, California. VRML97 is an academic and technical symposium sponsored by ACM SIGGRAPH and SIGCOMM, in cooperation with the VRML Consortium. This year's VRML Symposium provides a wide range of technical papers, educational opportunities, cutting-edge demonstrations and exhibits featuring the latest in VRML technology. The VRML Symposium home page is http://www.sdsc.edu/vrml97 400-500 attendees from across the globe are expected to attend this powerful 3-day technical symposium. Attendees can attend half-day or full-day tutorials, which are designed for both intermediate and advanced VRML users and developers. The Symposium also includes working groups, panels, academic papers and in-depth exhibitor demonstrations. Topics include 3D graphics, content, behaviors, interfaces, modeling, simulation, multi-user environments, networking and standards. The Hyatt Regency Monterey is headquarters hotel for VRML 97. For registration info, please refer to the VRML 97 home page http://www.sdsc.edu/vrml97/register.html or contact Lynn Johnson at 408-655-9924 or ljohnson@redshift.com. MBone production comments to vrlm97@cs.nps.navy.mil, scheduling conflicts to mccarthy@cs.nps.navy.mil Symposium MBone Broadcast Schedule: (Demo SIG, papers and panels to be broacasted live via Mbone) Monday, February 24, 1997 5:00 PM Demo SIG at the Hyatt Regency Ballroom - Timothy Childs (Sponsored by VeRGe and Microsoft) Tuesday, February 25, 1997 8:30 AM Papers: Implementation I, Val Watson session chair Using spatial techniques to decrease message passing in a distributed VE system, Olof Hagsand, Rodger Lea and Marten Stenius, Swedish Institute of Computer Science (SICS) and Sony Computer Science Lab An Object Oriented Approach to VRML Development, Curtis A. Beeson, Silicon Graphics Inc. Object-Oriented VRML for Multi-user Environments, Sungwoo Park 10:00 AM Break 10:00 AM Exhibits open 10:30 AM Papers: Multi-user, Dave Nadeau session chair Populating the Internet: Supporting Multiple Users and Shared Applications with VRML, Wolfgang Broll, German National Institute for Information Technology Community Place: architecture and performance, Rodger Lea, Yasuaki Honda, Kouichi Matsuda and Satoru Matsuda, Sony Computer Science Lab SpaceFusion: A multi-server architecture for shared virtual environments, Hiroyasu Sugano, Fujitsu 12:00 PM VRML Consortium Report: Elected VRML Consortium Inc. Board of Directors 2:00 PM Papers: Navigation and User Interface, Dave Kerlick session chair QOTA: A Fast, Multi-Purpose Algorithm For Terrain Following in Virtual Environments, John W. Barrus and Richard Waters, Mitsubishi Electric Research Laboratory MaPS: Movement and Planning Support for Navigation in an Immersive VRML Browser, John Edwards and Chris Hand, De Montfort University, Leicester UK Adapting VRML 2.0 for Immersive Use, Randy Stiles, Sandeep Tewari and Mihir Mehta, Lockheed Martin Advanced Technology Center 3:30 PM Break 4:00 PM Panel: Avatar and Multi-user Standards, Moderator Bernie Roehl - University of Waterloo, Mitra - ParaGraph, David Anderson - MERL, Yasuaki Honda - Sony Computer Science Lab 5:00 PM Panel: Using Java as a VRML development platform, Moderator: Jeff Close, Chris Marrin - SGI, Chris Laurel - Dimension X, John DeCuir - Sony Computer Research Laboratory 6:00 PM Break Wednesday, February 26, 1997 8:30 AM Plenary speaker: Tony Parisi, Intervista 9:00 AM Working group and workshop reports 10:00 AM Break 10:00 AM Exhibits open 10:30 AM Papers: Case Studies, Tamara Munzner session chair The Out of Box Experience: Lessons learned creating compelling VRML 2.0 content,Sam Chen, Rob Myers and Rick Pasetto, Silicon Graphics Inc. Networked VR System: Kitchen Layout Design for Customers, Tomohiro Fukuda, Ryuichiro Nagahama and Junji Nomura, Matsusita Electric Works Ltd. Animation for Performance Debugging of Parallel Computing Systems, Noritaka Osawa, Hisaya Morita and Toshitsugu Yuba, The University of Electro-Communications, Japan Using VRML to Access Manufacturing Data, Sandy Ressler, Qiming Wang, Scott Bodarky, Charles Sheppard and Gregory Seidman, National Institute of Standards and Technology 2:00 PM Papers: Implementation II, Dick Puk moderator V-COLLIDE: Accelerated Collision Detection for VRML, Tom Hudson, Ming C. Lin, Jon Cohen, Stefan Gottschalk and Dinesh Manocha, University of North Carolina Lodestar: An Octree-Based Level of Detail Generator for VRML, Dieter Schmalstieg, Vienna University of Technology, Austria Wired for Speed: Efficient Routes for VRML 2.0, Daniel Woods, Alan Norton and Gavin Bell, Silicon Graphics Inc. and Wazabi 3:00 PM Exhibits close, tear down 3:30 PM Break 4:00 PM Panel: Expanding Cyberspace: Persistence, Scalability, and Security in VRML, Moderator: Tony Parisi - Intervista Software, Clay Graham - tinySystems, Dan Lipkin - Oracle, Bob Rockwell - Black Sun Interactive 5:00 PM Panel: User Interface Design for Digital Space: 3d Navigation and Manipulation, Moderator: Bernie Roehl - University of Waterloo, Maclen Marvit - Worlds Inc., James Waldrop - Construct, Mark Pesce - Author 6:00 PM Symposium complete --PART-BOUNDARY=.19702201146.ZM22259.cs.nps.navy.mil-- From rem-conf-request@es.net Thu Feb 20 16:14:05 1997 Received: from dip.eecs.umich.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Feb 1997 13:13:08 -0800 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.8.5/8.8.0) id QAA04718; Thu, 20 Feb 1997 16:12:06 -0500 (EST) From: Dave Thaler Message-Id: <199702202112.QAA04718@dip.eecs.umich.edu> Subject: Re: Seminar: C. Huitema "The Internet Architecture - End-to-End To: crawdad@FNAL.GOV (Matt Crawford) Date: Thu, 20 Feb 1997 16:12:06 -0500 (EST) Cc: liao@ctr.columbia.edu, rem-conf@es.net, mnl@ctr.columbia.edu, campbell@ctr.columbia.edu In-Reply-To: <199702201709.LAA08584@gungnir.fnal.gov> from "Matt Crawford" at Feb 20, 97 11:09:39 am X-Mailer: ELM [version 2.4 PL24 PGP1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > I'm getting really weird looking video (although I can recognize > Christian) and no audio using the parameters in Raymond Liao's > message: > > > Multicast Address: > > audio: DVI, RTP, 224.2.243.158/30528/127 > > video: H.261, RTP, 224.2.154.154/59442/127 I experienced the same thing. I looked at "global stats" in vat-4.0b2 and it showed a bunch of wrong RTP version errors I think. I was able to listen in with rat-2.6a14 though. -Dave From rem-conf-request@es.net Fri Feb 21 08:44:09 1997 Received: from unix4.derby.ac.uk by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Feb 1997 05:43:28 -0800 Received: from sdk3.derby.ac.uk (sdk3.derby.ac.uk [193.63.43.18]) by unix4.derby.ac.uk (8.8.2/8.8.3) with ESMTP id NAA02270.; Fri, 21 Feb 1997 13:43:01 GMT Received: from SDK3/SpoolDir by sdk3.derby.ac.uk (Mercury 1.21); 21 Feb 97 13:42:39 +0 Received: from SpoolDir by SDK3 (Mercury 1.30); 21 Feb 97 13:42:01 +0 From: Markus Wiesinger Organization: University of Derby To: rem-conf@es.net Date: Fri, 21 Feb 1997 13:40:32 +0000 Subject: videoconferencing Return-receipt-to: "Markus Wiesinger" Priority: normal X-mailer: Pegasus Mail for Windows (v2.23) Message-ID: <4FAD1E8377C@sdk3.derby.ac.uk> I'm an exchange student from Austria studying at the University of Derby (Uk) and I currently work on a project dealing with videoconferencing. I am especially interested in desktop videoconferencing over ISDN and Internet. If you can give me further information on this topic please do not hesitate to do so. Scientific research documents would please me most. Thanks a lot, Markus Wiesinger e-mail: M.Wiesinger1@student.derby.ac.uk From rem-conf-request@es.net Fri Feb 21 16:22:01 1997 Received: from ns.research.att.com by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Feb 1997 13:21:12 -0800 Received: from research.research.att.com by ns; Fri Feb 21 16:20:03 EST 1997 Received: from surfcity.research.att.com by research; Fri Feb 21 16:19:28 EST 1997 Received: from pcmrc.research.att.com (pcmrc [135.16.211.43]) by surfcity.research.att.com (8.8.4/8.7.3) with SMTP id QAA17957; Fri, 21 Feb 1997 16:17:05 -0500 (EST) Message-ID: <330E1103.2D28@research.att.com> Date: Fri, 21 Feb 1997 16:17:56 -0500 From: "M. Reha Civanlar" Reply-To: civanlar@research.att.com Organization: AT&T Labs - Research X-Mailer: Mozilla 3.0Gold (Win95; I) MIME-Version: 1.0 To: Stephen Casner CC: rem-conf@es.net Subject: Re: Problems with RTP Payload Types References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I guess, one remaining question is how will one define new RTP payloads (not PT assignments) for these new codecs so that they can be archived as IETF documents. Is it viable that the AVT group continues to monitor this process for the foreseeable future? Stephen Casner wrote: > > Regarding the non-dynamic part of the space, it seems likely that many > new codecs will be used only with dynamic payload types throughout > their lifetime. Perhaps only (a subset of) those standardized by the > ITU will get static PT assignments. > -- Steve -- M. Reha Civanlar Principal Technical Staff Member, AT&T Labs - Research 101 Crawfords Corner Road, 4C520, Holmdel, NJ 07733-3030 (908) 949 6705 (908) 949 3697 (fax) civanlar@research.att.com http://www.research.att.com/info/mrc From rem-conf-request@es.net Fri Feb 21 18:03:48 1997 Received: from dirty.research.bell-labs.com by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Feb 1997 15:03:09 -0800 Received: from research.research.bell-labs.com by dirty; Fri Feb 21 18:02:04 EST 1997 Received: from sea.dnrc.bell-labs.com by research; Fri Feb 21 18:01:02 EST 1997 Received: from sea (localhost [127.0.0.1]) by sea.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id RAA10817; Fri, 21 Feb 1997 17:58:47 -0500 (EST) Sender: hgs@dnrc.bell-labs.com Message-ID: <330E28A7.1FC6@cs.columbia.edu> Date: Fri, 21 Feb 1997 17:58:47 -0500 From: "Henning Schulzrinne (BL)" Organization: Columbia University X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.4 sun4m) MIME-Version: 1.0 To: rem-conf@es.net, confctrl@isi.edu Subject: New version of RTSP draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A new draft of the RTSP specification is now available as PostScript at http://www.cs.columbia.edu/~hgs/rtsp/draft/rtsp.ps This will be submitted as an I-D in the next few days (after ASCIIfication). The draft raises a number of questions for discussion. The authors look forward to discussion and comments (on the confctrl mailing list or privately, if needed). Henning Henning Schulzrinne email: schulzrinne@cs.columbia.edu Dept. of Computer Science phone: +1 212 939-7042 Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs From rem-conf-request@es.net Mon Feb 24 07:48:45 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Feb 1997 00:27:10 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id AAA17491 for ; Mon, 24 Feb 1997 00:27:24 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma017487; Mon Feb 24 00:26:47 1997 Received: by hille.msri.org (8.7/MSRI) id AAA09796; Mon, 24 Feb 1997 00:26:13 -0800 (PST) Date: Mon, 24 Feb 1997 00:26:13 -0800 (PST) Message-Id: <199702240826.AAA09796@hille.msri.org> To: rem-conf@es.net From: multicast Reply-to: multicast@dxcoms.cern.ch Subject: Seminar on physics results from the LEP run at 172 GeV MBone Broadcast Announcement ---------------------------- Title: Seminar on physics results from the LEP run at 172 GeV Date: Feb 25, 1997 Time: 14:00 GMT+1 2 hours Contact: multicast@noc.cern.ch URL: http://sunmed2.cern.ch:8888/Seminar_25_02_97.html Description: mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Mon Feb 24 18:30:05 1997 Received: from lhc.nlm.nih.gov by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Feb 1997 09:33:31 -0800 Received: from billings.csb by lhc.nlm.nih.gov (SMI-8.6/SMI-SVR4) id MAA05987; Mon, 24 Feb 1997 12:35:44 -0500 Received: by billings.csb (SMI-8.6/SMI-SVR4) id MAA25215; Mon, 24 Feb 1997 12:31:22 -0500 Date: Mon, 24 Feb 1997 12:31:22 -0500 From: rodgers@nlm.nih.gov (R. P. C. Rodgers, M.D.) Message-Id: <199702241731.MAA25215@billings.csb> To: dem@fnal.gov, evi@boulder.Colorado.EDU, likavec@igd.fhg.de, mbone@isi.edu, rem-conf@es.net Subject: WWW6 Multicasting Plans To: rem-conf-request@es.net, mbone-request@isi.edu Subject: WWW6 Multicasting 7-11 April 1997 Dear MBONE/Net Colleagues, We would like to reserve the capability to multicast audio/video/wb/nt >from the Sixth International World Wide Conference, to be held 7-11 April 1997 at the Santa Clara Convention Center in Nothern California, USA. We realize that the IETF is occurring the same week, so will take extra care to coordinate our activities with our colleagues at the IETF to avoid generation of excessive bandwidth (hi there, Evi! 8^). We are tentatively announcing four channels via sdr (2 for live presentation, 2 for tape delay rebroadcast), though we would never have more than 2 running concurrently, and very likely not even that most of the time. We are not certain at this point if the tape delay rebroadcast will occur at all. Sdr announcments will be updated as plans firm up. In the tradition of recent conferences, we also anticipate the possibility of using one of the new webcasting tools to experimentally multicast some of the presenter's documents in html. The Web server for the Conf. is at: http://www6conf.slac.stanford.edu/, though it does not currently contain any information about multicasting schedules. For further information, please contact any of: David Martin (dem@fnal.gov) Jaromir Likavec (likavec@igd.fhg.de) Rick Rodgers (rodgers@.nlm.nih.gov) Best Regards, Rick Rodgers From rem-conf-request@es.net Mon Feb 24 18:44:10 1997 Received: from nobozo.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Feb 1997 10:18:25 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id KAA19811; Mon, 24 Feb 1997 10:18:24 -0800 Date: Mon, 24 Feb 1997 10:18:24 -0800 Message-Id: <199702241818.KAA19811@nobozo.CS.Berkeley.EDU> X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net, 298-list@bmrc.Berkeley.EDU From: Jerrlyn Iwata Subject: [Reminder] Berkeley Multimedia & Graphics Seminar Berkeley Multimedia and Graphics Seminar (Wednesday February 26, 1997 12:30-2:00 PDT 405 Soda Hall) "Why the Future of the Internet is not Multimedia and Other Assorted High Heresies" Mike O'Dell UUNET Technologies MBONE BROADCAST BEGINS AT 12.40 PDT (GMT - 8 HOURS) From rem-conf-request@es.net Tue Feb 25 10:06:50 1997 Received: from ernie.ucop.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Feb 1997 07:06:19 -0800 Received: from kali.ucop.edu (kali.ucop.edu [128.48.108.16]) by ernie.ucop.edu (8.8.4/8.8.4) with SMTP id HAA36828 for ; Tue, 25 Feb 1997 07:06:16 -0800 Message-Id: <3.0.1.32.19970225070431.0084dda0@popserv.ucop.edu> X-Sender: pchelp@popserv.ucop.edu X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 25 Feb 1997 07:04:31 -0800 To: rem-conf@es.net From: PC Center Subject: Windows mbone clients Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" I'd appreciate hearing about any free Windows based mbone clients I might try. From rem-conf-request@es.net Tue Feb 25 10:41:38 1997 Received: from iltwd02.italtel.it (actually ns.italtel.it) by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Feb 1997 07:41:02 -0800 Received: by iltwd02.italtel.it (5.65/sal-941215); id AA05544; Tue, 25 Feb 97 16:43:04 +0100 Received: by iltwd03.settimo.italtel.it (5.65/sal-941220); id AA09571; Tue, 25 Feb 97 16:40:10 +0100 Received: by ic8u32.settimo.italtel.it; id AA20973; Tue, 25 Feb 1997 16:40:36 +0100 Message-Id: <9702251540.AA20973@ic8u32.settimo.italtel.it> Received: from iltd74.settimo.italtel.it by ilt9h01 with SMTP (1.37.109.4/16.2) id AA06602; Tue, 25 Feb 97 16:38:49 -0500 Comments: Authenticated sender is From: Alessio Casati Organization: Italtel spa, a Stet and Siemens Company To: rem-conf@es.net Date: Tue, 25 Feb 1997 16:43:57 +0100 Subject: Re: Windows mbone clients Priority: normal X-Mailer: Pegasus Mail for Win32 (v2.42) > I'd appreciate hearing about any free Windows based mbone clients I might try. > > I'm interested in it too. Please make a pubblic reply. Thank you From rem-conf-request@es.net Tue Feb 25 11:14:01 1997 Received: from calvin.dgbt.doc.ca by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Feb 1997 08:13:26 -0800 Received: by calvin.dgbt.doc.ca (4.1/SMI-4.1) id AA15521; Tue, 25 Feb 97 11:13:20 EST Date: Tue, 25 Feb 97 11:13:20 EST From: andrew@calvin.dgbt.doc.ca (Andrew Patrick) Message-Id: <9702251613.AA15521@calvin.dgbt.doc.ca> Reply-To: andrew@calvin.dgbt.doc.ca X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rem-conf@es.net, mbone@ISI.EDU, multicast@canarie.ca Subject: "mpoll" - a new multicast polling tool As part of the MERCI project, I have been working on a new multicast application for real-time polling of opinions and ratings. "MPOLL" was developed with the following uses in mind: - collecting quality ratings during multicast sessions - collecting opinions and votes during multicast collaborative work sessions - collecting opinions on general topics or current events MPOLL may be useful during multicast sessions to get opinions from all the participants quickly and efficiently. It may also be useful for collecting quality and reception ratings during MBONE events. I am releasing MPOLL now to get some initial feedback, and will also be announcing an MPOLL test session via SDR (you will need a plugin). You can pick-up the current (very early Alpha) version of MPOLL at ftp://debra.dgbt.doc.ca/pub/mbone/mpoll/ source code and binaries for SunOS 4.1.4 and Solaris 2.5 are available. Please try the program and tell me what you think. Any and all feedback is welcome. Below are some more details about this program. You can also find more information at: http://debra.dgbt.doc.ca/mbone/mpoll/mpoll.html --------------------------------------------------------------------- MPOLL Version Alpha 2.* Andrew Patrick, Communications Research Centre Introduction ------------ "MPOLL" is a real-time opinion polling and rating collection tool that uses multicasting to distribute questions and responses to all multicast session participants. "MPOLL" was developed by Andrew Patrick at the Communications Research Centre (CRC) in Ottawa, Canada, as part of the MERCI project on Collaborative Work Tools. MPOLL was developed with the following uses in mind: - collecting quality ratings during multicast sessions - collecting opinions and votes during multicast collaborative work sessions - collecting opinions on general topics or current events Using MPOLL ----------- Usage: mpoll [-t ttl] [-C "title"] address/port OPTIONS: -C "title" : the theme title for the questions -t ttl : the multicast TTL (default = 15) MPOLL requires specifying a multicast address and port. MPOLL can be used by itself, or with other multicast tools such as VAT and VIC in an MBONE session. MPOLL can be started from SDR once an appropriate "plugin" is installed (see below), or from the command line. Command options that MPOLL accepts include the multicast TTL (-t), which defaults to 15, and a session title (-C), which defaults to "Unknown Theme". These are the same command options used by other multicast tools. Once MPOLL is started, there is built-in help for each of the windows that explains the features and functions. How MPOLL Works --------------- MPOLL works by sending question and response packets to the multicast address, and listening for packets from other hosts. The users can create a new question, and this will become available to all the users who have joined that multicast session. As users answer the question, the responses are distributed to all the participants, where they are tallied and displayed in a graphical histogram. MPOLL packets are redistributed periodically as long as the program is running, so that all current users will see all the results. Normally, MPOLL will be left running continuously during a polling period or multicast session. MPOLL uses a simple plain-text protocol for constructing multicast packets that is similar to the Session Description Protocol (SDP) used in SDR. There are currently 3 types of packets generated by MPOLL: questions, remove question instructions, and user responses. MPOLL creates a cache file in your home directory ("~/.mpoll_cache") for storing the questions from your last MPOLL session. This allows you to quit and restart MPOLL and have the questions for a session, yours and other users, reloaded. Installing MPOLL ---------------- Binary Distribution ------------------- The MPOLL binary file is a stand-alone C program that does not require any extra libraries in order to run. Simply copy the MPOLL program to a directory that is in your path. Currently, binary distributions of MPOLL are available for: - Solaris 2.5 - SunOS 4.1.4 A WIN32 port is planned. Anyone who can help to compile MPOLL for other platforms is asked to contact the author. Source Distribution ------------------- MPOLL is written in C and Tcl/Tk. The development environment is: - SPARC Solaris 2.5 - gcc version 2.7.2 - Tcl 7.6 / Tk 4.2 In addition, MPOLL uses the Embedded Tk (ET) toolkit by Richard Hipp (http://users.vnet.net/drh/ET.html) for integrating C and Tcl/Tk programming. Version 1.7.1 of ET is included in the MPOLL source distribution, and it must be installed before MPOLL is compiled. No configuration procedure is available yet for MPOLL. MPOLL has been developed under Solaris 2.5, so that is the default platform for make. Possible make commands are currently: For Solaris 2.5: "make" For SunOS 4.1.x: "make sunos" I would love to hear about any problems in building and running the program. Also, if you port MPOLL to another platform, please contact me with any information about changes necessary, and if you can supply a binary for my archive site. The SDR Plugin -------------- Since MPOLL is a new program, and polling is a new MBONE application, an appropriate media has not been defined in SDR. So, in order to use MPOLL from SDR you must install a "plugin". The plugin provided in the distribution is sdr2.plugin.S53.poll.udp.mpoll.mpoll and you should copy this to a "~/.sdr.plugins" dirctory on your system. See the SDR documentation for more information about plugins. Limitations ----------- - MPOLL currently has no unicast support - MPOLL currently only supports multiple-choice questions with 1 to 5 possible responses. Questions can be created that allow one or many responses from the users. - MPOLL is currently limited to 100 questions per session, and up to 5 possible answers per question. The question limit should be configurable be editing the MAX_TOPICS parameter in "mpoll.h", but changes to the MAX_RESPONSES parameter will probably not work. - MPOLL should someday read the ~/.RTPdefaults file, and perhaps some other X resources - a function to visibily remind users to update their responses should be added - we may need a function to edit an existing question Known Problems -------------- - this program is in an early Alpha stage of development. There are probably lots of features missing, and many bugs. - MPOLL has only been tested on Sun systems. No work on portability has been done yet. - no attempt is made to do robust font selection, so MPOLL will probably fail if the fonts I use are not on your system. See "mpoll.h" for the font definitions. - the command line args "-h or -help" dump core, use "--help" instead Acknowledgements ---------------- The protocol used in MPOLL is fashioned after the SDP protocol used in SDR, and I thank Mark Handley, Van Jacobson, and other contributors for their work on SDP and SDR. I also used the SDR source code as an example while working on MPOLL, and that code was useful for techniques like multicast socket management and periodic redistribution of packets. I learned a lot >from viewing other people's code, and I am sure that I made lots of mistakes, for which I am wholely responsible. Licence Terms ------------- Copyright (c) Communications Research Centre, Government of Canada 1997. All rights reserved. License is granted to copy and use this software, for research and evaluation purposes, provided that the Communications Research Centre is acknowledged in all documentation pertaining to any such copy or use. The Communications Research Centre grants no other licenses expressed or implied. Title, ownership rights, and intellectual property rights in the software shall remain with the Communications Research Centre. The Centre's name and the Government of Canada should not be used in any advertising without written permission. THE COMMUNICATIONS RESEARCH CENTRE MAKES NO REPRESENTATIONS CONCERNING EITHER THE MERCHANTABILITY OF THIS SOFTWARE OR THE SUITABILITY OF THIS SOFTWARE FOR ANY PARTICULAR PURPOSE. The software is provided "as is" without express or implied warranty of any kind. These notices must be retained in any copies of any part of this software. Author ------ Dr. Andrew Patrick Network Services & Interface Design Laboratory Communications Research Centre Industry Canada 3701 Carling Ave. P.O. Box 11490, Station 'H' Ottawa, ON CANADA K2H 8S2 Phone: (613) 990-4675 FAX: (613) 998-9648 E-Mail: andrew@calvin.dgbt.doc.ca WWW: http://debra.dgbt.doc.ca -- Andrew Patrick, Ph.D. http://debra.dgbt.doc.ca --> 1996 Psychic Report Card: http://www.csicop.org/articles/psychic-1996.html From rem-conf-request@es.net Tue Feb 25 12:57:37 1997 Received: from charon.finall.com by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Feb 1997 09:56:34 -0800 Received: from exchange.finall.com (exchange.finall.com [206.246.160.132]) by charon.finall.com (8.8.4/8.6.12) with SMTP id MAA21533 for ; Tue, 25 Feb 1997 12:56:28 -0500 (EST) Received: by exchange.finall.com with Microsoft Exchange (IMC 4.0.837.3) id <01BC231B.53724C60@exchange.finall.com>; Tue, 25 Feb 1997 12:56:33 -0500 Message-ID: From: "Jung, Michael" To: 'Alessio Casati' , "'rem-conf@es.net'" Subject: RE: Windows mbone clients Date: Tue, 25 Feb 1997 12:56:28 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit VIC, VAT, RAT, SDR, SD, Win32-SDR etc can be found at tis-archive.thepoint.net/Software/Internet/Interactive media/MBONE/ Note the space in "Interactive media" --mike Michael Jung mikej@finall.com >-----Original Message----- >From: Alessio Casati [SMTP:Alessio.Casati@italtel.it] >Sent: Tuesday, February 25, 1997 10:44 AM >To: rem-conf@es.net >Subject: Re: Windows mbone clients > > >> I'd appreciate hearing about any free Windows based mbone clients I >>might try. >> >> > >I'm interested in it too. Please make a pubblic reply. > >Thank you From rem-conf-request@es.net Tue Feb 25 13:08:46 1997 Received: from sirius.ctr.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Feb 1997 10:07:25 -0800 Received: from yosemite (liao@yosemite.ctr.columbia.edu [128.59.72.34]) by sirius.ctr.columbia.edu (8.8.5/8.6.4.287) with SMTP id NAA26112; Tue, 25 Feb 1997 13:07:12 -0500 (EST) Sender: liao@ctr.columbia.edu Message-ID: <33132A47.ABD322C@ctr.columbia.edu> Date: Tue, 25 Feb 1997 13:07:03 -0500 From: Raymond Liao Organization: CTR, Columbia University X-Mailer: Mozilla 3.0 (X11; I; SunOS 4.1.3 sun4c) MIME-Version: 1.0 To: rem-conf@es.net CC: mnl@ctr.columbia.edu Subject: Comet Group Seminar: H. V. Jagadish, AT&T Labs, Data Architectures for Managing Networks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MBone Broadcast Announcement Title: Data Architectures for Managing Networks: From Billing and Account Management to Real Time Performance Management Speaker: H. V. Jagadish AT&T Labs Date: Thursday, Feb. 27, 1997 Time: 10:00 AM - 11:00 AM EST Multicast Address: audio: DVI, RTP, 224.2.243.158/30528 , ttl=127 video: H.261, RTP, 224.2.154.154/59442 , ttl=127 Contact: Andrew T. Campbell URL: http://comet.ctr.columbia.edu/activities/seminars/ Place: Multimedia Network Laboratory 8LE1 Schapiro Research Building Center for Telecommunications Research Columbia University New York City, USA Abstract: In large networks, huge volumes of data are produced at the element level. The challenge is to aggregate this distributed and heteregeneous source of information in a manner that greatly decreases the volumes of data to be stored or communicated while still retaining the ability to answer queries of interest efficiently. We describe an approach to this problem in the context of a billing system, and hypothesize extensions of our approach toreal-time performance management. -- Raymond R.-F. Liao (212) 939-7158 http://www.ctr.columbia.edu/~liao Center for Telecommunications Research, Columbia University From rem-conf-request@es.net Tue Feb 25 13:24:55 1997 Received: from mailcom.videoconferencing.com by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Feb 1997 10:24:13 -0800 Received: by mailcom.videoconferencing.com with Microsoft Exchange (IMC 4.0.837.3) id <01BC231F.493C53E0@mailcom.videoconferencing.com>; Tue, 25 Feb 1997 13:24:53 -0500 Message-ID: X-MS-TNEF-Correlator: From: Matthew Feldman To: "'rem-conf@es.net'" Subject: FW: Windows mbone clients Date: Tue, 25 Feb 1997 13:24:00 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Encoding: 22 TEXT, 40 UUENCODE X-MS-Attachment: WINMAIL.DAT 0 00-00-1980 00:00 Me too. I heard the IPMI group may have some soon. Matthew Feldman ---------- From: Alessio Casati[SMTP:Alessio.Casati@italtel.it] Sent: Tuesday, February 25, 1997 10:43 AM To: rem-conf@es.net Subject: Re: Windows mbone clients > I'd appreciate hearing about any free Windows based mbone clients I might try. > > I'm interested in it too. Please make a pubblic reply. Thank you begin 600 WINMAIL.DAT M>)\^(C82`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$(@ <` M& ```$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`06 `P`.````S0<"`!D` M#0`8`````@`6`0$@@ ,`#@```,T'`@`9``T`& ````(`%@$!"8 !`"$```!% M-C)&-D)!.$5".$5$,#$Q0C5!-S X,# R0CE%,4-$0@!A!P$-@ 0``@````(` M`@`!!( !`!H```!&5SH@5VEN9&]W``@0`0```&4```!-151/ M3TE(14%21%1(14E034E'4D]54$U!64A!5D533TU%4T]/3DU!5%1(15=&14Q$ M34%.+2TM+2TM+2TM+4923TTZ04Q%4U-)3T-!4T%425--5% Z04Q%4U-)3T-! M4T%424!)``````,`$! ``````P`1$ `````"`0D0`0```%4"``!1`@``H00` M`$Q:1G7J`IPG_P`*`0\"%0*D`^0%ZP*#`% 3`U0"`&-H"L!S973N,@8`!L," M@S(#Q@<3`H,R,Q,/9C0$U@(`<'*B<1(@36%T"'!A!="&5 8`!01#87!I`9"T M;',"@S4/?Q"$?0J BPC/"=D[&H\R-34"@ <*@0VQ"V!N9S$P,V\4( L*$O(, M`6,`0 7092 @=&]O+@J%22 \:&4+$1^0(' @0%!-IR!0"< (8' @`,!Y(&#T M878?@',#<"(R`B ?UG\*CPN1%5(!T!9"(-$'X$8X96QD$6(+51@R,3<'(U\> MC2;[;&DQ-#1Y`M%I+2G3#- ITPM9,;8V)Q #8'0%D 5 +2QWKR;W*RL,,"OV M1@-A.BU^MROV#((3<&P'D "0;Q=1(G,68&E;4Q; 4#HU,34N,;1 %Y(L(&PN M_1>072T?+BT&8 (P+U\P:U)4"E!S9"'0+"6!8CQR=0K (> #4 G@0]=B,< )@$1< MH2!!;6EG: 5 =#D@CBY'R$U>'^8G;2 +@/LL(!J0F$== M&;$`5P`````#`/$_"00```,`)@```````P`V```````"`4<``0```#@```!C M/553.V$](#MP/4EN=&5L;&5C="!6:61E;R [;#U-04E,0T]-+3DW,#(R-3$X M,C0P,%HM,3@P``(!^3\!````80````````#`/@_`0```! ```!- M871T:&5W($9E;&1M86X``@'[/P$```!A`````````-RG0,C 0A :M+D(`"LO MX8(!`````````"]//4E.5$5,3$5#5"!6241%3R!#3TY&15)%3D-)3D`#T``0````4` M``!&5SH@``````L`*0``````"P`C```````"`7\``0```%@````\8SU54R5A M/5\E<#U);G1E;&QE8W1?5FED96]?)6P]34%)3$-/32TY-S R,C4Q.#(T,#!: F+3$X,$!M86EL8V]M+G9I9&5O8V]N9F5R96YC:6YG+F-O;3X`/70Q ` end From rem-conf-request@es.net Tue Feb 25 16:02:54 1997 Received: from engr.orst.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Feb 1997 13:01:57 -0800 Received: from eel (eel.ENGR.ORST.EDU [128.193.55.69]) by engr.orst.edu (8.8.5/8.8.5) with SMTP id NAA22617 for ; Tue, 25 Feb 1997 13:01:53 -0800 (PST) Received: from localhost by eel (SMI-8.6/ENGR-Client) id VAA10639; Tue, 25 Feb 1997 21:01:25 GMT Date: Tue, 25 Feb 1997 13:01:25 -0800 (PST) From: Stephane Chatre cc: rem-conf@es.net Subject: Multicast simulation In-Reply-To: <33132A47.ABD322C@ctr.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I would like to simulate an MBone session being multicasted using Matlab. For now, I'm looking for a model of network simulation. Does anyone know about tools/programs/matlab files available for network simulation? Thanks. Stephane ======================== Stephane Chatre Email: chatre@cs.orst.edu Department of Computer Science Phone: (541) 737-5583 (office) Oregon State University (541) 757-3376 (home) Life is what happens to you while you're busy making other plans. - John Lennon From rem-conf-request@es.net Tue Feb 25 16:50:39 1997 Received: from eagle.rvs.uni-hannover.de by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Feb 1997 13:49:11 -0800 Received: from borneo by eagle.rvs.uni-hannover.de with smtp (Smail3.1.28.1 #6) id m0vzUkG-00010KC; Tue, 25 Feb 97 22:49 MET Date: Tue, 25 Feb 1997 22:49:07 +0100 (MET) From: "Lutz Grueneberg, RVS" X-Sender: gruen@borneo To: Alessio Casati cc: rem-conf@es.net Subject: Re: Windows mbone clients In-Reply-To: <9702251540.AA20973@ic8u32.settimo.italtel.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, On Tue, 25 Feb 1997, Alessio Casati wrote: >=20 > > I'd appreciate hearing about any free Windows based mbone clients I mig= ht try.=20 > >=20 > >=20 >=20 > I'm interested in it too. Please make a pubblic reply. >=20 > Thank you >=20 A hopefully most current collection of tools for Win95 systems is available in the RVS Mbone Collection: ftp://ftp.rvs.uni-hannover.de/pub/products/mbone_collection/mbonew32.zip Collection of the tools for other OS are available from the same directory. German docs on the installation and usage of the tools is available: http://www.rvs.uni-hannover.de/products/mbone_collection Cheers, Lutz -- // Lutz Gr=FCneberg Lehrgebiet Rechnernetze und Verteilte Sy= steme // Universit=E4t Hannover // Schlo=DFwender Str. 5 // gruen@rvs.uni-hannover.de D-30159 Hannover, Germany // Public PGP-Key available: http://www.rvs.uni-hannover.de/people/gruen.ht= ml // http://bs.mit.edu:8001/pks-toplev.html From rem-conf-request@es.net Tue Feb 25 20:14:34 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Feb 1997 17:13:47 -0800 Received: from little-bear by precept.com (SMI-8.6/SMI-SVR4) id RAA08486; Tue, 25 Feb 1997 17:05:00 -0800 From: jcole@precept.com Message-Id: <970225170512.ZM3502@little-bear> Date: Tue, 25 Feb 1997 17:05:09 -0800 Reply-To: jcole@precept.com X-Mailer: Z-Mail 4.0 (4.0.0 Aug 21 1995) To: rem-conf@es.net Subject: Multicast of "ACM 97" Conference Sessions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precept Software will be transmitting 2 1/2 days worth of sessions from the ACM 97 Conference and Exposition in San Jose, California over the MBONE. The theme of the event is "The Next 50 Years Of Computing". Video will be H261, and audio will be PCM, both to be delivered using RTPv2 with Precept's IP/TV server software. Program Name: ACM 97 Start Date & Time: Mar/03/97 - 08:30 PST (16:30 GMT) Length: 7 1/2 Hours Program Name: ACM 97 Start Date & Time: Mar/04/97 - 08:30 PST (16:30 GMT) Length: 7 1/2 Hours Program Name: ACM 97 Start Date & Time: Mar/05/97 - 08:30 PST (16:30 GMT) Length: 3 1/2 Hours For more details, see http://www.acm.org/acm97/conference/sched.html. You can tune in to this MBONE event two ways. The event is being advertised with Precept's IP/TV Program Guide, which sends out an sdr-compatible session advertisement to be received by sdr or a local Program Guide server. Those who want to use Precept's viewer software for MS Windows but are not running a local Program Guide may access the one at www.precept.com (this is set by default for the downloaded viewer). Also located on that web site are details on downloading the viewer. ACM has requested this copyright notice be included in the session advertisement... --- Copyright c 1997 ACM, Association for Computing The files distributed by this server have been provided by ACM. Copyright and all rights therein are maintained by ACM. It is understood that all persons copying this information will adhere to the terms and constraints invoked by ACM+s copyright. These works may not be reposted without the explicit permission of ACM. Reuse and/or reposting for noncommercial classroom use is permitted. Questions regarding usage rights and permissions may be addressed to: permissions@acm.org --- -- John Cole, Systems Engineer Tel: 415.845.5217 Precept Software, Inc. Fax: 415.845.5235 1072 Arastradero Road http://www.precept.com Palo Alto, CA 94304 E-Mail: jcole@precept.com From rem-conf-request@es.net Wed Feb 26 00:42:18 1997 Received: from hyowon.cc.pusan.ac.kr by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Feb 1997 21:41:22 -0800 Received: from khkim.ce.pusan.ac.kr ([164.125.200.34]) by hyowon.cc.pusan.ac.kr (5.x/Hyowon-MX-1.0) id AA18740; Wed, 26 Feb 1997 14:40:20 +0900 Message-Id: <3.0.32.19970226144431.006a5ad8@hyowon.pusan.ac.kr> X-Sender: kimkh@hyowon.pusan.ac.kr X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 26 Feb 1997 14:44:35 +0900 To: rem-conf@es.net From: Kim KuHwan Subject: Subscribe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" subscribe From rem-conf-request@es.net Wed Feb 26 04:07:12 1997 Received: from nmi-gate.netmanage.co.il by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Feb 1997 01:06:15 -0800 Received: from Amirb32bit.netmanage.co.il (maor1.netmanage.co.il [156.27.241.48]) by nmi-gate.netmanage.co.il (8.6.9/8.6.9) with SMTP id LAA07808 for ; Wed, 26 Feb 1997 11:07:10 +0200 Date: Wed, 26 Feb 1997 11:05:52 +0200 From: Amir Belogorodsky Subject: Unsubscribe To: rem-conf@es.net X-Mailer: Chameleon ATX ZM61_24, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <3.0.32.19970226144431.006a5ad8@hyowon.pusan.ac.kr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe From rem-conf-request@es.net Wed Feb 26 08:46:15 1997 Received: from spider.innercite.com (actually www.lloyd.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Feb 1997 05:45:39 -0800 Received: from cperey.innercite.com (kate-26.innercite.com [158.222.32.251]) by spider.innercite.com (8.7.5/8.7.3) with SMTP id FAA08304; Wed, 26 Feb 1997 05:45:33 -0800 (PST) Message-Id: <2.2.32.19970226104750.00ad3284@spider.lloyd.com> X-Sender: cperey@spider.lloyd.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Feb 1997 05:47:50 -0500 To: hermenh@ix.netcom.com, rem-conf@es.net From: Christine Perey Subject: Re: earn $75 How is your study going? CP From rem-conf-request@es.net Wed Feb 26 14:30:10 1997 Received: from mail1.digital.com by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Feb 1997 11:29:32 -0800 Received: from bigpink.pa.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA30527; Wed, 26 Feb 1997 11:21:51 -0800 Received: by bigpink.pa.dec.com; id AA10102; Wed, 26 Feb 1997 11:21:46 -0800 Message-Id: <9702261921.AA10102@bigpink.pa.dec.com> To: rem-conf@es.net Cc: band@std.org Subject: Severe Tire Damage tonight ~8pm PST Date: Wed, 26 Feb 97 11:21:46 -0800 From: berc@pa.dec.com X-Mts: smtp Who: Severe Tire Damage What: Rock & Roll Where: The Fabulous SubForum, Palo Alto CA When: 26-Feb-97 ~8pm PST Why: Would you rather smoke two joints or do your homework? I knew you were going to say that! Another session of Severe Tire Damage mcasting their bandwidth-friendly message of love to their growing international audience. This week an interview crew from Stern (guten tag bis Deutchland) will be on hand to buy decent beer. Camera control will be available from www.std.org via the "remote cam" link. I don't know if we'll have the web controlled mixer or fog machine set up this evening. Many thanks to those who've offered to translate the article in "InternNet Guiden" from Swedish. We now have a reasonable version in English, though some phrases like "We know that STD is magnetic, but it is magnetic in such new and interesting ways" may have gained new meaning in the process. From rem-conf-request@es.net Wed Feb 26 18:46:01 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Feb 1997 15:45:10 -0800 Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id PAA12042; Wed, 26 Feb 1997 15:27:30 -0800 Date: Wed, 26 Feb 1997 15:29:40 -0800 () From: Stephen Casner To: Arlie Davis cc: rem-conf@es.net Subject: RE: Progressing IDMR items In-Reply-To: Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Arlie, > RTCP puts a much greater strain than is necessary on (S,G)-state > implementations. This is rather unfortunate. Both on the rem-conf list and in the last AVT meeting, we have had significant discussion of the use of RTCP in large broadcast scenarios. I'll attempt to move this discussion back there [bcc to mbone]. > Imagine 5 million people watching a single multicast of the NFL Super > Bowl. Instead of N routers maintaining state for a single (S,G) pair, > they have to maintain 5,000,001 (S,G) pairs, _no matter how infrequently > the receivers advertise_. Aggravating, isn't it? With a shared-tree routing protocol, there is only (*,G) state for the receivers because the RTCP data rate is low enough not to trigger the formation of a source-rooted tree. > Also, truly, RTCP data isn't always that interesting. Do I really care > that much who is listening to the same radio broadcast? If it's a > conference, yes. If it's a broadcast, usually no. At the AVT meeting, we concluded that there should be additional RTP profiles specifying alternative RTCP behavior. It is likely that one of those would specify that receivers would not send RTCP at all, for use in scenarios where privacy of reception or other factors outweigh the value of RTCP's reception feedback. BTW, at the AVT meeting I invited the submission of proposals for additional profiles, but I don't think any such proposals have been submitted yet. (Not to neglect Bernard Aboba's I-D on the issues and the useful email on this topic.) -- Steve From rem-conf-request@es.net Thu Feb 27 01:59:00 1997 Received: from itu.cc.jyu.fi by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Feb 1997 22:58:14 -0800 Received: from localhost (localhost [127.0.0.1]) by itu.cc.jyu.fi (8.8.4/8.8.4) with SMTP id IAA02725; Thu, 27 Feb 1997 08:57:48 +0200 Date: Thu, 27 Feb 1997 08:57:48 +0200 (EET) From: Seppo Kallio To: Christine Perey cc: hermenh@ix.netcom.com, rem-conf@es.net Subject: Re: earn $75 In-Reply-To: <2.2.32.19970226104750.00ad3284@spider.lloyd.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 26 Feb 1997, Christine Perey wrote: > How is your study going? > > CP No problems. Seppo From rem-conf-request@es.net Thu Feb 27 09:49:32 1997 Received: from burdell.cc.gatech.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Feb 1997 06:48:57 -0800 Received: from flora.cc.gatech.edu (kevin@flora.cc.gatech.edu [130.207.8.20]) by burdell.cc.gatech.edu (8.8.4/8.6.9) with ESMTP id JAA19664 for ; Thu, 27 Feb 1997 09:48:55 -0500 (EST) Received: (from kevin@localhost) by flora.cc.gatech.edu (8.8.4/8.6.9) id JAA13106 for rem-conf@es.net; Thu, 27 Feb 1997 09:48:54 -0500 (EST) Date: Thu, 27 Feb 1997 09:48:54 -0500 (EST) From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199702271448.JAA13106@flora.cc.gatech.edu> To: rem-conf@es.net Subject: Vic from a file In my thesis writing-induced haze I cannot remember if I have ever successfully asked or had the following question answered: Has anyone hacked vic, or is there an option to allow someone to pipe a file (created through the SunVideo GUI for example) I realize a hack to the source may not be too difficult, but I'd prefer not to duplicate effort. RTPdump and RTPplay are great for analog to digital conversion but there really isn't any way to get existing digital content (in the proper format) onto the MBone. -Kevin Almeroth From rem-conf-request@es.net Thu Feb 27 13:18:04 1997 Received: from nobozo.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Feb 1997 10:17:18 -0800 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id KAA05446; Thu, 27 Feb 1997 10:17:14 -0800 Date: Thu, 27 Feb 1997 10:17:14 -0800 Message-Id: <199702271817.KAA05446@nobozo.CS.Berkeley.EDU> X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: 298-list@bmrc.Berkeley.EDU, rem-conf@es.net From: Jerrlyn Iwata Subject: Berkeley Multimedia & Graphics Seminar Berkeley Multimedia and Graphics Seminar (Wednesday March 5, 1997 12:30-2:00 PDT 405 Soda Hall) "The Internet as a Populated Place" Pavel Curtis PlaceWare, Inc. Advances in technology are radically changing the face of the Internet, from a huge, comprehensive, but lonely library into a vast web of interconnected places bustling with live human presences. I'll talk about how these changes are finally making it possible for people all over the world to use the Internet as a whole as a vast, powerful tool for interpersonal communication, collaboration, and sharing. -------------------------------------------------------------------------------- This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40 PDT (GMT - 8 hrs). See sdr or http://bmrc.berkeley.edu/298 for instructions on setting up, connecting to, and operating the MBONE tools. Please direct all technical questions to davesimp@cs.berkeley.edu From rem-conf-request@es.net Thu Feb 27 13:53:03 1997 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Feb 1997 10:52:17 -0800 Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id KAA13161 for ; Thu, 27 Feb 1997 10:52:06 -0800 (PST) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.6/8.7.3) id KAA05551 for rem-conf@es.net; Thu, 27 Feb 1997 10:52:12 -0800 (PST) Original-Received: by ccm.hf.intel.com (ccmgate 3.2 #7) Thu, 27 Feb 97 10:52:12 PST PP-warning: Illegal Received field on preceding line Date: Thu, 27 Feb 97 10:50:00 PST From: John H Wilson Message-ID: To: rem-conf@es.net Subject: RTSP "sessions", "streams", "components", and URIs IMHO, RTSP could avoid some confusion over the term "session" by being self-consistent. SDP defines the term in one sense: a collection of streams with a common time-line. RTP defines the term in another sense: a single media stream (along with its parallel "control" stream (RTP/RTCP). RTSP has absorbed both terms. In Section 1.3, it is used in the SDP sense; in section 6.2, GET retrieves a session description, and in section 6.11, SESSION allows the server to send the client a modified session description with new or deleted "components" (it is not clear, but I think "component" is synonymous with "stream".) In section 8.24, session is clearly refering to a single stream (consistent with RTP, but RTSP does not insist on its use). It defines the session header field which identifies the state of a single stream on which SETUP(6.3), PLAY(6.4), PAUSE(6.5), and CLOSE(6.6) operate. IMHO, "stream" should be used for SETUP, PLAY, PAUSE, CLOSE, and should replace the term "component" in the definition of the SESSION request. The "session" header field would become the "stream" header field. On a minor, related, point, I wonder why all requests must contain a Request-URI. PAUSE and CLOSE, for example, must operate on an existing "stream"; if the Request-URI does not match the "stream" ID, I suppose it is a protocol error? What would the Request-URI be used for in these two requests? john_h_wilson@ccm.jf.intel.com From rem-conf-request@es.net Thu Feb 27 14:10:31 1997 Received: from george.arc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Feb 1997 11:09:54 -0800 Received: by george.arc.nasa.gov (8.7.1/1.35) id LAA13865; Thu, 27 Feb 1997 11:09:49 -0800 (PST) Date: Thu, 27 Feb 1997 11:09:49 -0800 (PST) Message-Id: <199702271909.LAA13865@george.arc.nasa.gov> From: lamaster@george.arc.nasa.gov To: mbone@isi.edu Subject: RE: Progressing IDMR items Cc: rem-conf@es.net [ "Arlie Davis" wrote:] |> >> Imagine 5 million people watching a single multicast of the NFL Super |> >> Bowl. Instead of N routers maintaining state for a single (S,G) pair, |> >> they have to maintain 5,000,001 (S,G) pairs, _no matter how infrequently |> >> the receivers advertise_. Aggravating, isn't it? ["Dino Farinacci" :] |> One would also argue that the RTCP backoff as the group gets larger is |> more of a detriment to routers, since the (S,G) timeout will occur |> more frequently than the RTCP transmission interval. Therefore, in a |> dense-mode router, there is a malloc() for every transmission of the |> 5,000,001 sources to create (S,G) state. This can't be good in any |> router both from a memory fragmentation point of view and a switching |> point of view. I think it might make sense to, by default, automatically drop individual RTCP transmissions back to the source at a certain point. [And, certainly, there should be an option to do so. See below]. OTOH, RTCP has proven useful [to me] in cases where there are on the order of 1000 listeners. But, at a certain point, individual RTCP listener reports would seem to no longer make sense. I'm not suggesting that no feedback to the source be given. It would often be extremely useful to know how many people are watching. But, long before one got to TV/radio-sized audiences- 10^^6 listeners- you would only want to know about how many people are watching, not who. [Unless "you" are the secret police, or something [e.g. Advertisers]. See Privacy below.] Given the example above, how many listeners does it take before the RTCP transmission interval drops to below the timeout threshold? Maybe that is ~about a logical place to switch. Likewise, if the average time someone tunes in to an Internet Radio program is short relative to the average retransmission time, the statistics would no longer be valid anyway. Maybe there is a better way to estimate the number of listeners when large-scale broadcasts are involved. |> >> Also, truly, RTCP data isn't always that interesting. Do I really care |> >> that much who is listening to the same radio broadcast? If it's a |> >> conference, yes. If it's a broadcast, usually no. As above, for small broadcasts, yes, it is useful. I don't think one should take the TV analogy too far - for purely TV-like functions, with on the order of 10-200 possible "channels", you already have: FM radio, AM radio, broadcast TV, cable TV, DirecTV [and other satellite TV companies], and so on. Does anyone think that "The Mbone" is going to be able to deliver MPEG1/2/HDTV quality video into the home worldwide in direct competition to DirecTV and/etc.???? For little more than the cost of connecting to an ISP with a 28.8 modem, today you can already get MPEG1/2 quality [ie, better than VCR, better than most cable] satellite TV. Even when the entire Internet is higher-bandwidth, multimedia, multicast enabled, I still don't see the Internet in direct competition with existing systems. I see the "broadcast market" for mbone-like capability to be analogous to the Shuttle broadcasts- smaller, "niche" markets and communities too small and geographically diverse to get air time on a cable or satellite system with a few hundred channels. In other words, the same as the internet today, but multicast/multimedia enabled. The appeal of the internet has always been individual and "niche" communication, not "mass" communication, for which efficient channels have already long existed. Sure, we need to make sure everything scales up to a large number of internet users, maybe even 6 billion, but, I doubt if they want to be internet users so they can "watch TV". People can already do that, *more cheaply*, just by watching TV. In fact, this diversity, from a routing point of view, represents one of the challenges: millions of daytime professional internet users now want their own personal class C home networks, and they want routes to similar people. Now, add multicast. Anyway, getting back to RTCP and "niche" broadcasting, assuming a larger number of smaller, niche sources: If we are talking about 1000-10000 listeners to one of 10,000 different multicast broadcast sources, then, yes, RTCP would be very useful, including the information on how well "most people" are receiving the broadcast. Do we really want to |> >> burden precious router resources with (S,G) state that is of dubious |> >> value? As Steve Casner above, and Dino Farinacci below, point out, this concern is (now) invalid. A shared tree will handle the RTCP listener report flow, and the traffic will scale back to a proportionately small amount. I *am* still concerned about the total amount of (memory) state routers have to carry, but, not for *this* case. If 5 million of people are watching the same broadcast, so what if there are a few router bytes allocated for multicast? We just need to make sure that everything scales up for this exceptional case, but, frankly, I doubt seriously whether this will be a constant widespread problem any time soon. [Of much larger concern is the amount of router memory consumed by 10^^5 DIS-like ~100-person multiuser games along the lines of what Intel described at their interactive multimedia/etc. presentation last summer. If you want to worry about something, worry about that. I really don't think RTCP is much of a problem.] In short, RTCP could be enhanced to scale to millions of people who are listening over asymmetric- bandwidth media [e.g. cable modems], and also for Privacy. ---- [Dino Farinacci:] |> This is why SPT thresholds were created in PIM. If you set the SPT |> threshold in a cisco to say 8kbps, only the active "speakers" get an |> (S,G), everyone else uses the (*,G). And, Steve Casner also replied: ["Stephen Casner" :] [Arlie Davis:] |> > RTCP puts a much greater strain than is necessary on (S,G)-state |> > implementations. This is rather unfortunate. |> |> Both on the rem-conf list and in the last AVT meeting, we have had |> significant discussion of the use of RTCP in large broadcast |> scenarios. I'll attempt to move this discussion back there [bcc to |> mbone]. : |> With a shared-tree routing protocol, there is only (*,G) state for the |> receivers because the RTCP data rate is low enough not to trigger the |> formation of a source-rooted tree. |> > Also, truly, RTCP data isn't always that interesting. Do I really care |> > that much who is listening to the same radio broadcast? If it's a |> > conference, yes. If it's a broadcast, usually no. |> |> At the AVT meeting, we concluded that there should be additional RTP |> profiles specifying alternative RTCP behavior. It is likely that one |> of those would specify that receivers would not send RTCP at all, for |> use in scenarios where privacy of reception or other factors outweigh |> the value of RTCP's reception feedback. |> |> BTW, at the AVT meeting I invited the submission of proposals for |> additional profiles, but I don't think any such proposals have been |> submitted yet. (Not to neglect Bernard Aboba's I-D on the issues and |> the useful email on this topic.) --- One of the things which several people at IETF requested, after a similar discussion to this mailing list discussion, [I guess nobody has responded with anything concrete] was some method to [reliably] estimate the number of listeners without actually getting individual reports. Normally, it is a Bad Thing to ask Routers to do something other than Route, so, this method likely should be something driven by the multicast source itself, to which [some of] the receivers can [randomly] respond, if asked. Also, if we are talking about millions of viewers and commercially significant advertising dollars possibly based on viewership, then, there probably needs to be some kind of difficult-to-spoof authentication built in, too. After all, what is there, today, to prevent a single source from falsifying non-existent-listener reports? So, we need a statistically valid, authenticated, but private, low-upstream-bandwidth, router-independent method for estimating viewership. Ideas? -Hugh LaMaster From rem-conf-request@es.net Thu Feb 27 15:17:21 1997 Received: from cs.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Feb 1997 12:16:31 -0800 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id PAA09989; Thu, 27 Feb 1997 15:16:27 -0500 (EST) Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id PAA14494; Thu, 27 Feb 1997 15:16:18 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <3315EB91.6BFD@cs.columbia.edu> Date: Thu, 27 Feb 1997 15:16:17 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: John H Wilson CC: robla@prognet.com, rem-conf@es.net, confctrl@isi.edu Subject: Re: RTSP "sessions", "streams", "components", and URIs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks for pointing this out - all the authors are aware that the current terminology is both inconsistently used within and outside the document. One proposal would be use the terms "track" and "presentation", since stream has too many conflicting uses already. (RTSP "lives in" both the SDP name space and the RTP name space, for better and for worse.) Just using "session" doesn't help, since we do need to name individual media streams (say, only the audio part of a movie). I cc'ed this to confctrl, I think that's where the discussion belongs. John H Wilson wrote: > > IMHO, RTSP could avoid some confusion over the term "session" by being > self-consistent. > > SDP defines the term in one sense: a collection of streams with a common > time-line. > > RTP defines the term in another sense: a single media stream (along with > its parallel "control" stream (RTP/RTCP). > > RTSP has absorbed both terms. > > In Section 1.3, it is used in the SDP sense; in section 6.2, GET > retrieves a session description, and in section 6.11, SESSION allows the > server to send the client a modified session description with new or > deleted "components" (it is not clear, but I think "component" is > synonymous with "stream".) > > In section 8.24, session is clearly refering to a single stream > (consistent with RTP, but RTSP does not insist on its use). It defines > the session header field which identifies the state of a single stream > on which SETUP(6.3), PLAY(6.4), PAUSE(6.5), and CLOSE(6.6) operate. > > IMHO, "stream" should be used for SETUP, PLAY, PAUSE, CLOSE, and should > replace the term "component" in the definition of the SESSION request. > The "session" header field would become the "stream" header field. > > On a minor, related, point, I wonder why all requests must contain a > Request-URI. PAUSE and CLOSE, for example, must operate on an existing > "stream"; if the Request-URI does not match the "stream" ID, I suppose > it is a protocol error? What would the Request-URI be used for in these > two requests? You can PAUSE and CLOSE an individual track (say, the audio track) without PAUSEing or CLOSEing the whole presentation (audio and video, say) or you can indeed PAUSE the whole show. The session id is the same in both cases, the URI is not. "Invalid session id" is, I think, one of the possible error codes. (Whether Session should be a concept within RTSP or whether RTSP should borrow the HTTP state maintenance mechanisms for its purposes is another debate...) > > john_h_wilson@ccm.jf.intel.com Henning -- Henning Schulzrinne email: schulzrinne@cs.columbia.edu Dept. of Computer Science phone: +1 212 939-7042 Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs From rem-conf-request@es.net Thu Feb 27 15:27:46 1997 Received: from silver.sms.fi by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Feb 1997 12:26:45 -0800 Received: (from pete@localhost) by silver.sms.fi (8.8.5/8.7.3) id WAA09634; Thu, 27 Feb 1997 22:26:34 +0200 (EET) Date: Thu, 27 Feb 1997 22:26:34 +0200 (EET) Message-Id: <199702272026.WAA09634@silver.sms.fi> From: Petri Helenius To: lamaster@george.arc.nasa.gov Cc: mbone@isi.edu, rem-conf@es.net Subject: RE: Progressing IDMR items In-Reply-To: <199702271909.LAA13865@george.arc.nasa.gov> References: <199702271909.LAA13865@george.arc.nasa.gov> lamaster@george.arc.nasa.gov writes: > DirecTV [and other satellite TV companies], and so on. Does > anyone think that "The Mbone" is going to be able to deliver > MPEG1/2/HDTV quality video into the home worldwide in direct > competition to DirecTV and/etc.???? For little more than the I'm in for this one. Many companies in US and abroad have announced *DSL offerings in the sub-$100/month range. That's in the ballpark what you pay for your cable, phone and 28.8 ISP connection. (but does or is going to do you much more than that) > cost of connecting to an ISP with a 28.8 modem, today you can > already get MPEG1/2 quality [ie, better than VCR, better than > most cable] satellite TV. Even when the entire Internet is > higher-bandwidth, multimedia, multicast enabled, I still don't > see the Internet in direct competition with existing systems. > I don't want to talk about competing either, I would call it replacement. After you have the bits flowing you don't need to have a wire per purpose. You can have it all from the same wire. > I see the "broadcast market" for mbone-like capability to be > analogous to the Shuttle broadcasts- smaller, "niche" markets > and communities too small and geographically diverse to get > air time on a cable or satellite system with a few hundred > channels. In other words, the same as the internet today, > but multicast/multimedia enabled. The appeal of the internet > has always been individual and "niche" communication, not > "mass" communication, for which efficient channels have already > long existed. Sure, we need to make sure everything scales up The issue here that the incremental cost of doing both is extremely small. (if going from the "small" market content to mass market, the other direction is more expensive) > to a large number of internet users, maybe even 6 billion, but, > I doubt if they want to be internet users so they can "watch TV". > People can already do that, *more cheaply*, just by watching TV. > I disagree with the cost argument here. With the digital television technology, all is going to be bits anyway, so I don't think consumers are going to really care what delivers their bits. As long as they get the bits. Also there is huge forces behind on the integration on computing devices and larger screens (read: PC and TV) to provide multimedia content to the couch potatoes. > In fact, this diversity, from a routing point of view, > represents one of the challenges: millions of daytime > professional internet users now want their own personal > class C home networks, and they want routes to similar > people. Now, add multicast. > Remember CIDR? An average home does not need eight bits address space (yet). I used to have a C-class network at home but swapped it to 4 bit subnet some while back (just to be a good citizen). > Anyway, getting back to RTCP and "niche" broadcasting, assuming > a larger number of smaller, niche sources: If we are talking > about 1000-10000 listeners to one of 10,000 different multicast > broadcast sources, then, yes, RTCP would be very useful, including > the information on how well "most people" are receiving the broadcast. > You can build your apps to send the RTCP messages to the source, not to the multicast group. This way the RTCP "problem" goes away. Regardless of the routing protocol. I for myself wouldn't care of my neighbor knowing what I watch on my "internet television" nor I would like you to know. > [Of much larger concern is the amount of router memory consumed > by 10^^5 DIS-like ~100-person multiuser games along the lines > of what Intel described at their interactive multimedia/etc. > presentation last summer. If you want to worry about something, > worry about that. I really don't think RTCP is much of a problem.] Exactly :-) In a game everybody is a source. That's going to be the greater challenge. > > In short, RTCP could be enhanced to scale to millions > of people who are listening over asymmetric- bandwidth > media [e.g. cable modems], and also for Privacy. > Glad that you mentioned privacy as an issue too. > > Also, if we are talking about millions of viewers and > commercially significant advertising dollars possibly based > on viewership, then, there probably needs to be some kind > of difficult-to-spoof authentication built in, too. After all, > what is there, today, to prevent a single source from falsifying > non-existent-listener reports? So, we need a statistically > valid, authenticated, but private, low-upstream-bandwidth, > router-independent method for estimating viewership. Ideas? > I think the keyword here is "estimating". The figures need to be in the ballpark but they do not need to be exact. However, no clever technical ideas come into mind right now :-( Pete From rem-conf-request@es.net Thu Feb 27 16:26:28 1997 Received: from tis-mail.thepoint.net (actually tis-backup.thepoint.net) by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Feb 1997 13:25:08 -0800 Received: by tis-mail.thepoint.net with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC24CA.C8DF4380@tis-mail.thepoint.net>; Thu, 27 Feb 1997 16:25:03 -0500 Message-ID: From: Arlie Davis To: "'lamaster@george.arc.nasa.gov'" Cc: "'mbone@isi.edu'" , "'rem-conf@es.net'" Subject: RE: Progressing IDMR items Date: Thu, 27 Feb 1997 16:25:01 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Simply tossing RTCP packets toward the source is not a good idea at all. The source may be a machine with minimal intelligence, whose sole responsibility is to read digital video and multicast it, for example, or a stream server who could care less about membership. Also, there would be a huge flood of RTCP packets toward the source. So, there are two issues that I have with this: The source may not be interested, and the flood of packets may be too great. There are two relatively easy ways to deal with this. Let "session watcher" mean a machine which is interested in the RTCP reports for a given multicast source or session, and "session source" mean the machine which is actually sourcing the data, such as video or audio. The session source could periodically multicast a list of preferred session watchers. (How this information is conveyed is irrelevant -- it could be in-band RTP data with a specific, reserved payload type, or any number of ways. The only important thing is that the data is multicast to the exact same set of machines who are receiving the data multicast.) Each RTCP-aware client would receive the list of session watchers and randomly decide on which one to use. (If the list of session watchers changes (watchers arrive, go away), the clients just re-decide.) Then, the client unicasts it's RTCP data to the session watcher. This would allow for very simple and very complex implementations. The simplest implementations would announce a fixed list that just points toward the session source. The more complex ones would manage a distributed database of all of the session listeners, their quality-of-service statistics, etc. Also, in the same place that specifies the list of session watchers, the session source could simply indicate that clients are to send their RTCP the "old fashioned way" -- multicast it to the same group as the session data. This would be a good choice for small- and medium-sized group conferences. The above model makes sense mostly for traditional broadcast-style multicasts (few sources, many many listeners). As we all know, the higher the group membership, the lower the rate at which the members announce themselves. As we approach Large numbers of listeners, the rate essentially approaches zero, which makes RTCP pretty much useless. In a large session, usually there are only a few people truly interested in who is listening. Why not have the session watcher(s) collect this information, index it, and (for example) make it available via a web query. -- arlie >-----Original Message----- >From: lamaster@george.arc.nasa.gov [SMTP:lamaster@george.arc.nasa.gov] >Sent: Thursday, February 27, 1997 2:10 PM >To: mbone@isi.edu >Cc: rem-conf@es.net >Subject: RE: Progressing IDMR items > >I think it might make sense to, by default, automatically drop >individual RTCP transmissions back to the source at a certain point. >[And, certainly, there should be an option to do so. See below]. > >OTOH, RTCP has proven useful [to me] in cases where there are on >the order of 1000 listeners. But, at a certain point, individual >RTCP listener reports would seem to no longer make sense. I'm not >suggesting that no feedback to the source be given. It would often >be extremely useful to know how many people are watching. But, long >before one got to TV/radio-sized audiences- 10^^6 listeners- you >would only want to know about how many people are watching, not who. >[Unless "you" are the secret police, or something [e.g. Advertisers]. >See Privacy below.] > >Given the example above, how many listeners does it take before >the RTCP transmission interval drops to below the timeout threshold? >Maybe that is ~about a logical place to switch. Likewise, if the >average time someone tunes in to an Internet Radio program is short >relative to the average retransmission time, the statistics would >no longer be valid anyway. Maybe there is a better way to estimate >the number of listeners when large-scale broadcasts are involved. > >|> >> Also, truly, RTCP data isn't always that interesting. Do I really care >|> >> that much who is listening to the same radio broadcast? If it's a >|> >> conference, yes. If it's a broadcast, usually no. > >As above, for small broadcasts, yes, it is useful. I don't think >one should take the TV analogy too far - for purely TV-like >functions, with on the order of 10-200 possible "channels", >you already have: FM radio, AM radio, broadcast TV, cable TV, >DirecTV [and other satellite TV companies], and so on. Does >anyone think that "The Mbone" is going to be able to deliver >MPEG1/2/HDTV quality video into the home worldwide in direct >competition to DirecTV and/etc.???? For little more than the >cost of connecting to an ISP with a 28.8 modem, today you can >already get MPEG1/2 quality [ie, better than VCR, better than >most cable] satellite TV. Even when the entire Internet is >higher-bandwidth, multimedia, multicast enabled, I still don't >see the Internet in direct competition with existing systems. > >I see the "broadcast market" for mbone-like capability to be >analogous to the Shuttle broadcasts- smaller, "niche" markets >and communities too small and geographically diverse to get >air time on a cable or satellite system with a few hundred >channels. In other words, the same as the internet today, >but multicast/multimedia enabled. The appeal of the internet >has always been individual and "niche" communication, not >"mass" communication, for which efficient channels have already >long existed. Sure, we need to make sure everything scales up >to a large number of internet users, maybe even 6 billion, but, >I doubt if they want to be internet users so they can "watch TV". >People can already do that, *more cheaply*, just by watching TV. > >In fact, this diversity, from a routing point of view, >represents one of the challenges: millions of daytime >professional internet users now want their own personal >class C home networks, and they want routes to similar >people. Now, add multicast. > >Anyway, getting back to RTCP and "niche" broadcasting, assuming >a larger number of smaller, niche sources: If we are talking >about 1000-10000 listeners to one of 10,000 different multicast >broadcast sources, then, yes, RTCP would be very useful, including >the information on how well "most people" are receiving the broadcast. > > Do we really want to >|> >> burden precious router resources with (S,G) state that is of dubious >|> >> value? > >As Steve Casner above, and Dino Farinacci below, point out, >this concern is (now) invalid. A shared tree will handle the >RTCP listener report flow, and the traffic will scale back >to a proportionately small amount. > >I *am* still concerned about the total amount of (memory) >state routers have to carry, but, not for *this* case. >If 5 million of people are watching the same broadcast, >so what if there are a few router bytes allocated for multicast? >We just need to make sure that everything scales up for >this exceptional case, but, frankly, I doubt seriously >whether this will be a constant widespread problem any >time soon. > >[Of much larger concern is the amount of router memory consumed >by 10^^5 DIS-like ~100-person multiuser games along the lines >of what Intel described at their interactive multimedia/etc. >presentation last summer. If you want to worry about something, >worry about that. I really don't think RTCP is much of a problem.] > >In short, RTCP could be enhanced to scale to millions >of people who are listening over asymmetric- bandwidth >media [e.g. cable modems], and also for Privacy. > >|> At the AVT meeting, we concluded that there should be additional RTP >|> profiles specifying alternative RTCP behavior. It is likely that one >|> of those would specify that receivers would not send RTCP at all, for >|> use in scenarios where privacy of reception or other factors outweigh >|> the value of RTCP's reception feedback. > From rem-conf-request@es.net Thu Feb 27 20:50:13 1997 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Feb 1997 17:25:50 -0800 Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id RAA18600; Thu, 27 Feb 1997 17:25:39 -0800 (PST) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.6/8.7.3) id RAA25376; Thu, 27 Feb 1997 17:25:46 -0800 (PST) Original-Received: by ccm.jf.intel.com (ccmgate 3.2 #6) Thu, 27 Feb 97 17:25:46 PST PP-warning: Illegal Received field on preceding line Date: Thu, 27 Feb 97 17:19:00 PST From: John H Wilson Message-ID: To: schulzrinne , rem-conf-request@es.net cc: robla@prognet.com, rem-conf@es.net, confctrl@isi.edu Subject: Re[2]: RTSP "sessions", "streams", "components", and URIs Text item: OK, suppose we use "Presentation" instead of "Session" and "Track" instead of "Stream" I'm still a bit puzzled about the model: You wrote: >You can PAUSE and CLOSE an individual track (say, the audio track) >without PAUSEing or CLOSEing the whole presentation (audio and video, >say) or you can indeed PAUSE the whole show. The session id is the same >in both cases, the URI is not. "Invalid session id" is, I think, one of >the possible error codes. (Whether Session should be a concept within >RTSP or whether RTSP should borrow the HTTP state maintenance mechanisms >for its purposes is another debate...) My questions are: 1. I assume SETUP is always track-specific; whether it is the intial SETUP or not. 2. I assume that a PLAY that does not specify a track id, must specifiy a track URI, and gets a track id in return. (I.e., cannot operate on a presentation basis) True? 3. Is there such a thing as a presentation id? I assume not, since I see no request that generates one. 4. If (as you say) the "session id" is the same to PAUSE/CLOSE either a presentation or a track, and the difference is in the URI, then to PAUSE/CLOSE a presentation, I must be able to use ANY track id in the presentation + the presentation URI....true? If this is the case, I assume that, once a presentation has been PAUSEd, it can be resumed by sending a PLAY with ANY track id + the presentation URI? 5. I assume that track id's are not client unique. If there are multiple listeners to a track (it is being multicast), these clients can provide some way to pass the track id around, so that any of them can use the same (track id + URI) to PAUSE/PLAY/CLOSE the track. This is the so-called "pass the remote" scenario, except that RTSP provides no mechanism to prevent "multiple remotes"? [So far, I've concluded that SETUP is track-specific, while PLAY, PAUSE & CLOSE are not.] Two presentation description questions: - SDP does not seem provide the necessary track-specific URI information; do you intend to propose the necessary extensions? - where can I find a definition of SDF? john_h_wilson@ccm.jf.intel.com Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii References: Subject: Re: RTSP "sessions", "streams", "components", and URIs CC: robla@prognet.com, rem-conf@es.net, confctrl@isi.edu To: John H Wilson MIME-Version: 1.0 X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u) Organization: Columbia University, Dept. of Computer Science From: Henning Schulzrinne Date: Thu, 27 Feb 1997 15:16:17 -0500 Message-ID: <3315EB91.6BFD@cs.columbia.edu> Sender: hgs@cs.columbia.edu Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id PAA14494; Thu, 27 Feb 1997 15:16:18 -0500 (EST) Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id PAA09989; Thu, 27 Feb 1997 15:16:27 -0500 (EST) Received: from cs.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Feb 1997 12:16:31 -0800 Received: from osi-west.es.net (osi-west.es.net [198.128.3.61]) by ormail.intel.com (8.8.4/8.8.4) with SMTP id PAA00836; Thu, 27 Feb 1997 15:55:40 -0800 (PST) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i ntel.com (8.7.6/8.7.3) with ESMTP id PAA08232; Thu, 27 Feb 1997 15:55:50 -0800 ( PST) Return-Path: rem-conf-request@es.net From rem-conf-request@es.net Fri Feb 28 03:08:25 1997 Received: from silver.sms.fi by osi-west.es.net with ESnet SMTP (PP); Fri, 28 Feb 1997 00:07:17 -0800 Received: (from pete@localhost) by silver.sms.fi (8.8.5/8.7.3) id KAA10752; Fri, 28 Feb 1997 10:07:05 +0200 (EET) Date: Fri, 28 Feb 1997 10:07:05 +0200 (EET) Message-Id: <199702280807.KAA10752@silver.sms.fi> From: Petri Helenius To: Arlie Davis Cc: "'lamaster@george.arc.nasa.gov'" , "'mbone@isi.edu'" , "'rem-conf@es.net'" Subject: RE: Progressing IDMR items In-Reply-To: References: Arlie Davis writes: > Simply tossing RTCP packets toward the source is not a good idea at all. > The source may be a machine with minimal intelligence, whose sole > responsibility is to read digital video and multicast it, for example, > or a stream server who could care less about membership. > > Also, there would be a huge flood of RTCP packets toward the source. I should have been more clear here. I'm not suggesting that this should be done without indication from the source to do so. The source should tell the receivers either send the RTCP packets to the group, send them to the source or not send them at all. > > The session source could periodically multicast a list of preferred > session watchers. (How this information is conveyed is irrelevant -- it > could be in-band RTP data with a specific, reserved payload type, or any > number of ways. The only important thing is that the data is multicast > to the exact same set of machines who are receiving the data multicast.) > Each RTCP-aware client would receive the list of session watchers and > randomly decide on which one to use. (If the list of session watchers > changes (watchers arrive, go away), the clients just re-decide.) Then, > the client unicasts it's RTCP data to the session watcher. This is a good optimization of what I propose above. > Pete From rem-conf-request@es.net Fri Feb 28 03:16:33 1997 Received: from itu.cc.jyu.fi by osi-west.es.net with ESnet SMTP (PP); Fri, 28 Feb 1997 00:15:43 -0800 Received: from localhost (localhost [127.0.0.1]) by itu.cc.jyu.fi (8.8.4/8.8.4) with SMTP id KAA21938 for ; Fri, 28 Feb 1997 10:15:50 +0200 Date: Fri, 28 Feb 1997 10:15:49 +0200 (EET) From: Seppo Kallio To: rem-conf@es.net Subject: Vic binaries for Linux RedHat 4.1+b/w QuickCam + MatroxMeteor In-Reply-To: <199702271448.JAA13106@flora.cc.gatech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Is there binaries or easy to port sources for vic using b/w qcam and vic using Matrox Meteor? I tryed to compile vic-2.8, but have some problems with it. Need some fast grabber for Meteor olso, is metgrab ported to Linux? I would like to do some mpegs. Seppo From rem-conf-request@es.net Fri Feb 28 09:18:24 1997 Received: from burdell.cc.gatech.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 28 Feb 1997 06:17:45 -0800 Received: from flora.cc.gatech.edu (kevin@flora.cc.gatech.edu [130.207.8.20]) by burdell.cc.gatech.edu (8.8.4/8.6.9) with ESMTP id JAA09537 for ; Fri, 28 Feb 1997 09:17:39 -0500 (EST) Received: (from kevin@localhost) by flora.cc.gatech.edu (8.8.4/8.6.9) id JAA16163 for rem-conf@es.net; Fri, 28 Feb 1997 09:17:38 -0500 (EST) Date: Fri, 28 Feb 1997 09:17:38 -0500 (EST) From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199702281417.JAA16163@flora.cc.gatech.edu> To: rem-conf@es.net Subject: RE: Progressing IDMR items [Pruned MBone list, just 'case I hate sending to both] >>From: lamaster@george.arc.nasa.gov >>most cable] satellite TV. Even when the entire Internet is >>higher-bandwidth, multimedia, multicast enabled, I still don't >>see the Internet in direct competition with existing systems. I do! :-) But let's not meander on predictions. >>As Steve Casner above, and Dino Farinacci below, point out, >>this concern is (now) invalid. A shared tree will handle the >>RTCP listener report flow, and the traffic will scale back >>to a proportionately small amount. Pulling more statistics from my mlisten stuff, I've noted that the ratio of RTCP traffic to RTP traffic is typically pretty well behaved. For all the audio sessions the RTCP traffic lately has been about 6-8 Kbps. While this number is dependent on the total number of receivers (lately it has been about averaging about 75 because not much is going on) there is another factor. And that is the number of groups. As the number of groups grows the RTCP traffic will increase (scaling only works within a group). Something to consider. Oh, and the video traffic has been behaving similarly. >>["Stephen Casner" :] >> >>|> At the AVT meeting, we concluded that there should be additional RTP >>|> profiles specifying alternative RTCP behavior. It is likely that one >>|> of those would specify that receivers would not send RTCP at all, for >>|> use in scenarios where privacy of reception or other factors outweigh >>|> the value of RTCP's reception feedback. Sorry I missed this discussion. A careful analysis of existing sessions would yield some good insight into the number and types of profiles needed. >>Normally, it is a Bad Thing to ask Routers to do >>something other than Route, so, this method likely >>should be something driven by the multicast source itself, >>to which [some of] the receivers can [randomly] respond, >>if asked. Probabilistic feedback has been shown to be quite accurate. -Kevin Almeroth From rem-conf-request@es.net Fri Feb 28 16:45:13 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 28 Feb 1997 13:44:39 -0800 Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id NAA18124; Fri, 28 Feb 1997 13:23:53 -0800 Date: Fri, 28 Feb 1997 13:26:19 -0800 () From: Stephen Casner To: rem-conf@es.net Subject: RE: Progressing IDMR items In-Reply-To: <199702281417.JAA16163@flora.cc.gatech.edu> Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm replying to several messages here that present a range of ideas. Most of these ideas were discussed in the last AVT meeting, minutes of which were sent to this list and are accessible from www.ietf.org. There you can see a list of the solutions that have been proposed and some potential problems that can arise. "Dino Farinacci" : > |> Therefore, in a > |> dense-mode router, there is a malloc() for every transmission of the > |> 5,000,001 sources to create (S,G) state. Right, so using a shared tree to eliminate this cost is a big win. Then the (S,G) state timeout is not an issue. lamaster@george.arc.nasa.gov writes: > I think it might make sense to, by default, automatically drop > individual RTCP transmissions back to the source at a certain point. I see trouble in making an automatic transision. Since the RTCP packets from other participants are the means to determine how many participants there are, when the threshold is crossed and some stop sending RTCP, then the count will drop below the threshold again and this will oscillate. Instead, I believe the different RTCP modes should be selected by the choice of a particular RTP profile specified as a session parameter. > One of the things which several people at IETF requested, > after a similar discussion to this mailing list discussion, > [I guess nobody has responded with anything concrete] > was some method to [reliably] estimate the number of > listeners without actually getting individual reports. I think the question was slightly different: how to estimate the number of receivers without having to store the SSRC id's from all the RTCP packets you've heard. This can be done with a sampling technique, which I think was described in messages to the list. > Normally, it is a Bad Thing to ask Routers to do > something other than Route, so, this method likely > should be something driven by the multicast source itself, > to which [some of] the receivers can [randomly] respond, > if asked. The scalability of IP multicast (in number of receivers) derives directly from the fact that no entity needs to know how many receivers there are. So, the routers could not really answer the question anyway. On Thu, 27 Feb 1997, Petri Helenius wrote: > You can build your apps to send the RTCP messages to the source, not > to the multicast group. This way the RTCP "problem" goes away. The problem is to avoid an implosion at the sender. We discussed ways of letting the sender control the responses by sampling the receivers, including work by Wakeman, Bolot and Turletti a couple of years ago. On Thu, 27 Feb 1997, Arlie Davis wrote: > The session source could periodically multicast a list of preferred > session watchers. (How this information is conveyed is irrelevant -- it > could be in-band RTP data with a specific, reserved payload type, or any > number of ways. The only important thing is that the data is multicast > to the exact same set of machines who are receiving the data multicast.) > Each RTCP-aware client would receive the list of session watchers and > randomly decide on which one to use. (If the list of session watchers > changes (watchers arrive, go away), the clients just re-decide.) Then, > the client unicasts it's RTCP data to the session watcher. Indeed, it may be desirable to have the reception reporting go to one or more third-party monitors ("session watchers") rather than the sender. However, you still need to control the rate at which clients send, because they won't be hearing the multicast RTCP packets to adapt for themselves. So, presumably the sender or some other entity needs to tell them how often to send as well as where to send. As Henning Schulzrinne pointed out, this provides an easy way for some malicious entity to instruct all the receivers to packet bomb some other innocent party. > As we all know, the higher the group membership, the lower the rate at > which the members announce themselves. As we approach Large numbers of > listeners, the rate essentially approaches zero, which makes RTCP pretty > much useless. The long interval may prevent collecting a complete list of who is listening, but you still get feedback about loss rate that, in the aggregate over all receivers, comes in quite frequently. On Fri, 28 Feb 1997, Petri Helenius wrote: > > Also, there would be a huge flood of RTCP packets toward the source. > > I should have been more clear here. I'm not suggesting that this > should be done without indication from the source to do so. The source > should tell the receivers either send the RTCP packets to the group, > send them to the source or not send them at all. Again, it is essential to control the rate as well as the destination. Also, if there is more than one source, having the source specify the mode can be problematic. Also, unless the default is to send nothing at all, the source could get swamped before it had a chance to tell the receivers what to do. But this default is not good for small teleconferences. For these reasons, I believe this should be a session-specific parameter. On Fri, 28 Feb 1997, Kevin C. Almeroth wrote: > As the number of groups grows the RTCP > traffic will increase (scaling only works within a group). Something > to consider. Sure, but so will the data traffic. We assume that the network capacity will increase over time to handle the demand. The current situation of having several channels that are up all the time but idle most of the time is artificial, I think. > Sorry I missed this discussion. A careful analysis of existing sessions > would yield some good insight into the number and types of profiles needed. That would be welcome. -- Steve From rem-conf-request@es.net Fri Feb 28 16:50:47 1997 Received: from ANLCHM.CHM.ANL.GOV by osi-west.es.net with ESnet SMTP (PP); Fri, 28 Feb 1997 13:50:05 -0800 Received: from anchm3 by ANLCHM.CHM.ANL.GOV with SMTP; Fri, 28 Feb 1997 15:47:20 -0600 (CST) Message-Id: <3.0.1.32.19970228155055.009477b0@anlchm.chm.anl.gov> X-Sender: clmarshall@anlchm.chm.anl.gov X-Mailer: Windows Eudora Pro Version 3.0.1 beta 13 (32) Date: Fri, 28 Feb 1997 15:50:55 -0600 To: rem-conf@es.net, mbone@anl.gov From: Chris Marshall Subject: Mbone Broadcast of Seminar Cc: mike_petrick@qmgate.anl.gov (Michael Petrick/ANL), bertolac@che.udel.edu (Ralph Bertolacini/Amoco/retired), mmarino@anl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" On Thursday, March 6, 1997 the Argonne Petroleum Seminar Series will broadcast the following seminar live. The broadcast will begin at 10:30 am CST. Visit the Argonne Petroleum Seminar Series web site at (http://www.anl.gov/Petroleum) for further information. REFINERY ENERGY EFFICIENCY ECONOMICS (ABSTRACT BELOW) Jerry L. Robertson (Retired Engineering Advisor Exxon Research and Engineering Co.) Sr. Consultant ____________________________________________ As a preliminary test to this live broadcast we will be broadcasting two of the 1996 talks from 10 am to 2 pm on March 4 & 5, 1997. These talks are: "Catalysis in the Petroleum Industry Research Strategies for the Late Nineties and Beyond" Paul B. Venuto Retired Manager of Catalysis Mobil R & D Central Research Division "Trends in Fluid Cracking Catalyst Technology" Carmo J. Pereira W. R. Grace & Company ________________________________________________ REFINERY ENERGY EFFICIENCY ECONOMICS ABSTRACT Petroleum Refineries are large complex systems. In the base case typical scenerio a few crude feeds produce many products, through a set of processes. The product mix and specifications change with season. Furthermore, since most of the products are ultimately burned, many of the constituent product molecules are interchangeable among products-- for example jet fuel and gasoline. Individual conversion, desulfurization, separation and other processes are connected either directly or through intermediate tankage which means that changes in refinery feeds or intermediate processing conditions are reflected in changes in the product streams. Design techniques have required the partitioning of the effort so that, for example, the crude pipe still, cat cracker, catalytic reformer, cat light ends, cat deethanizer absorber are individually designed with a specific window of feed and product throughput and specifications. On top of the process requirements, a set of energy systems--the utility system--includes: steam at several pressure levels, electric power, cooling water and a fuel gas system provides additional process interconnectivity. Most refinery systems have been modified many times by adding new processes or revamping existing ones for bottleneck removal or new operating conditions. This typical scenario provides a refinery that consists of many reactors, heat exchangers, distillation towers, drums, pumps compressors, etc. connected together with various sizes of pipes and controlled with an array of control valves. Because of the interactions, large scale of the problem and difficulty in making meaningful cost studies, many energy conservation studies and projects have resulted in less than acceptable results. Steam has been saved on the basis of its marginal cost to one process only to have the steam vent open in another part of the refinery when the project was installed. Similarly heat pumps have been installed to reboil distillation towers saving low pressure steam that could have easily been generated by waste heat in an adjacent process. Systems have been designed with too much heat exchange in one process area and too little in others. Major studies have been done (and even books written) to save availability. These sometimes, but not always, resulting in economic energy efficiency. This seminar will outline an economics driven method for providing a consistent approach to refinery wide energy efficiency. The method is based on the refinery wide compositing of the heat requirements for all of the processes (from feed to reactor inlet). Similarly, the heat availability from all the hot reactor outlets on the way to other processes or product tankage are also composited. This pinch analysis approach is expanded by calculation of the marginal value of energy saved (based on its actual cost) versus the marginal cost of effective heat exchange area (or additional heat transfer coefficient). The technique is then expanded to determine the value of marginal energy saved versus temperature. Use of this value provides a consistent goal for energy saving projects across the entire refinery and assures consistent approach temperatures for the design of various energy recovery exchangers. It also allows justification of heat transfer coefficient enhancers such as turbulence promoters or anti foulents on an economically consistent basis. While the method might appear to be useful only to design, it is also useful to both daily and longer term operations of refineries. It can be used to relate the value of marginal internal product (such as vacuum gas oil or catalytic reformer feed) to the cost of energy for additional recovery. Finally it can be used to adjust operational stewardship goals such as allowable energy consumption for a specific process unit to current economics and operating parameters. =============================================== Christopher L. Marshall, Research Scientist Chemistry Division/Coal Chemistry Group Argonne National Laboratory, CHM/200 9700 South Cass Avenue Argonne, IL 60439-4831 =============================================== E-mail: CLMARSHALL@ANL.GOV Phone: (630)252-4310 Fax: (630)252-9288 =============================================== Current Issues in Petroleum Processing Seminar Series at Argonne < http://www.anl.gov/Petroleum > 15th North American Catalysis Society Meeting, Chicago, 1997 < http://www.anl.gov/NAM > =============================================== From rem-conf-request@es.net Fri Feb 28 22:07:33 1997 Received: from monitor.internaut.com (actually Cust50.Max24.Seattle.WA.MS.UU.NET) by osi-west.es.net with ESnet SMTP (PP); Fri, 28 Feb 1997 19:07:00 -0800 Received: from multi ([204.57.137.9]) by monitor.internaut.com (8.7.6/8.6.12) with SMTP id TAA22815 for ; Fri, 28 Feb 1997 19:05:21 -0800 (PST) Received: by multi with Microsoft Mail id <01BC25AA.1CAE8A40@multi>; Fri, 28 Feb 1997 19:03:41 -0800 Message-ID: <01BC25AA.1CAE8A40@multi> From: Bernard Aboba To: "rem-conf@es.net" Subject: Profiles Date: Fri, 28 Feb 1997 19:03:39 -0800 Encoding: 15 TEXT OK, I'll bite. The profile I would like to see would be: A profile that brings the bandwidth fraction down below 5 percent. To prevent this from being used for abusive purposes, it could be interpretted as a fraction of 5 percent. That way, you could specify a bandwidth fraction of less than 5 percent, but never more. Setting the fraction to zero would be equivalent to turning off RTCP entirely. While we talked about a number of other possibilities at the AVT meeting, in thinking more about them, I'm either convinced that they don't help (putting RTCP on a separate group), or could be abused too easily (sending RTCP to a unicast address).