From rem-conf-request@es.net Fri Nov 01 00:20:23 1996 Received: from dfw-ix12.ix.netcom.com by osi-east.es.net with ESnet SMTP (PP); Thu, 31 Oct 1996 21:19:54 -0800 Received: from home (wor-ma1-14.ix.netcom.com [205.184.168.46]) by dfw-ix12.ix.netcom.com (8.6.13/8.6.12) with SMTP id VAA23797 for ; Thu, 31 Oct 1996 21:19:47 -0800 Message-ID: <326EB2E4.693A@ix.netcom.com> Date: Wed, 23 Oct 1996 19:05:56 -0500 From: Stuart Nixdorff Reply-To: stuartn@ix.netcom.com X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe From rem-conf-request@es.net Fri Nov 01 06:47:43 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Fri, 1 Nov 1996 03:46:40 -0800 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 1 Nov 1996 10:54:19 +0000 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: rem-conf@es.net cc: M.Handley@cs.ucl.ac.uk Subject: New version of Sdr (2.3a1) and Sdr source available Date: Fri, 01 Nov 1996 10:54:16 +0000 Message-ID: <17598.846845656@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk An experimental version of sdr (2.3a1) is now in ftp://cs.ucl.ac.uk/mice/sdr/ This includes many bug fixes and also includes the ability to make private session announcements. Note: the code for private announcements isn't really well tested - I think it works OK, but I wouldn't trust it for anything very private right now! The SAP packet headers more or loss conform to the SAP draft in ftp://ftp.isi.edu/confctrl/docs/ but I'll release a new draft soon to fix the things that have changed. This version of sdr doesn't implement strong authentication, but work on this will continue at UCL after I've left. Sdr source is now also available in ftp://cs.ucl.ac.uk/mice/sdr/ Please do mail me about bugs/problems, but bear in mind that this release was somewhat rushed - I know there are a few problems, and that I may not be able to read email for a little while. Mark From rem-conf-request@es.net Fri Nov 01 08:50:59 1996 Received: from user1.scranton.com by osi-east.es.net with ESnet SMTP (PP); Fri, 1 Nov 1996 05:50:21 -0800 Received: from localhost (garcia@localhost) by user1.scranton.com (8.6.12/8.6.9) with SMTP id IAA15596 for ; Fri, 1 Nov 1996 08:51:35 -0500 X-Authentication-Warning: user1.scranton.com: garcia owned process doing -bs Date: Fri, 1 Nov 1996 08:51:35 -0500 (EST) From: Joe Garcia To: rem-conf@es.net Subject: unsubscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII this is my third attempt to unsubscribe. please facilitate ASAP! ---------- unsubscribe From rem-conf-request@es.net Fri Nov 01 11:45:07 1996 Received: from premise.CS.Berkeley.EDU by osi-east.es.net with ESnet SMTP (PP); Fri, 1 Nov 1996 08:44:22 -0800 Received: from premise.CS.Berkeley.EDU (bmah@localhost.Berkeley.EDU [127.0.0.1]) by premise.CS.Berkeley.EDU (8.8.2/8.8.2) with ESMTP id IAA14678; Fri, 1 Nov 1996 08:44:16 -0800 (PST) Message-Id: <199611011644.IAA14678@premise.CS.Berkeley.EDU> X-Mailer: exmh version 1.6.9 8/22/96 To: rem-conf@es.net cc: bmah@cs.berkeley.edu Subject: MBone RTP Audio anomalies? From: bmah@cs.berkeley.edu (Bruce A. Mah) Reply-to: bmah@cs.berkeley.edu X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Nov 1996 08:44:13 -0800 Sender: bmah@premise.CS.Berkeley.EDU I've been looking at (live) IP multicast packet traces this morning (PST). I'm looking at a stream of packets for the Mbone RTP Audio session ('tcpdump host 224.2.0.1'), and am noticing something rather strange. Most hosts seem to be sending packets (updates for the user list I presume, since there appears to be no audio data) in clumps of two or three, but a few seem to be sending packets in bursts that are many tens of packets long. While not fatal, this looks kind of odd. Is there some easy explanation for this that I'm missing? (Queueing in the network causing *lots* of jitter?) Bruce. From rem-conf-request@es.net Fri Nov 01 12:43:59 1996 Received: from hill.msri.org (actually msri.org) by osi-east.es.net with ESnet SMTP (PP); Fri, 1 Nov 1996 09:42:57 -0800 Received: by hill.msri.org (8.7/1.43r) id KAA00161; Fri, 1 Nov 1996 10:42:58 -0700 (PPET) From: dave@msri.org (Dave Wright) Received: from gauss.msri.org(198.129.65.58) by msri.org via smap (V1.3) id sma000151; Fri Nov 1 10:42:33 1996 Received: by gauss.msri.org (8.7/MSRI) id JAA04222; Fri, 1 Nov 1996 09:41:48 -0800 (PST) Message-Id: <199611011741.JAA04222@gauss.msri.org> Subject: Re: MBone RTP Audio anomalies? To: bmah@cs.berkeley.edu Date: Fri, 1 Nov 1996 09:41:48 -0800 (PST) Cc: rem-conf@es.net In-Reply-To: <199611011644.IAA14678@premise.CS.Berkeley.EDU> from "Bruce A. Mah" at Nov 1, 96 08:44:13 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit : : I've been looking at (live) IP multicast packet traces this morning (PST). : I'm looking at a stream of packets for the Mbone RTP Audio session ('tcpdump : host 224.2.0.1'), and am noticing something rather strange. Most hosts seem : to be sending packets (updates for the user list I presume, since there : appears to be no audio data) in clumps of two or three, but a few seem to be : sending packets in bursts that are many tens of packets long. : : While not fatal, this looks kind of odd. Is there some easy explanation for : this that I'm missing? (Queueing in the network causing *lots* of jitter?) : : Bruce. : : : : : Yesterday I was getting RPF Failed for hosts in my subnet connecting to any groups. This morning I see that other are having the same problem. I know that RPF is a function of PIM in dense mode but not sure how to fix it. Group: 224.2.0.1, Source count: 27, Group pkt count: 606484 RP-tree: 1174247/10/94/7 Source: 13.2.116.11/32, 185651/5/101/3 Source: 128.2.211.15/32, 1485/0/82/0 Source: 128.32.33.58/32, 184/0/94/0 Source: 128.32.33.172/32, 185/0/88/0 Source: 128.32.33.199/32, 178/0/93/0 Source: 128.102.80.100/32, 12134/0/101/0, RPF Failed: 302 Source: 128.223.156.117/32, 12546/0/101/0, RPF Failed: 367 Source: 131.243.64.35/32, 92553/0/88/0, RPF Failed: 347 Source: 134.95.129.23/32, 10517/0/102/0, RPF Failed: 335 Source: 138.25.8.74/32, 1074/0/86/0 Source: 140.173.8.3/32, 175667/0/89/0 Source: 140.185.50.3/32, 17/0/91/0 Source: 141.89.192.6/32, 946/0/88/0 Source: 147.6.9.91/32, 11385/0/94/0, RPF Failed: 337 Source: 163.205.180.60/32, 1067/0/108/0 Source: 171.69.58.81/32, 13447/0/86/0, RPF Failed: 390 Source: 171.69.129.220/32, 13390/0/93/0, RPF Failed: 421 Source: 192.9.9.71/32, 33053/0/89/0, RPF Failed: 1018 Source: 192.33.16.7/32, 10340/0/88/0, RPF Failed: 343 Source: 192.188.104.56/32, 586/0/120/0 Source: 192.188.104.97/32, 2232/0/116/0 Source: 192.188.104.98/32, 4026/0/132/0 Source: 198.129.65.88/32, 0/0/0/0, RPF Failed: 20 Source: 198.211.79.3/32, 809/0/102/0 Source: 199.94.220.184/32, 9460/0/95/0, RPF Failed: 321 Source: 204.123.13.69/32, 12517/0/82/0, RPF Failed: 369 Source: 206.24.0.5/32, 1055/0/85/0 ________ o Dave Wright _______ _/\_> dave@msri.org _______O=>// O 89HawkGT 91CBR600F2 AFM# 316 -------------- Mathematical Sciences Research Institute From rem-conf-request@es.net Fri Nov 01 12:47:14 1996 Received: from hill.msri.org (actually msri.org) by osi-east.es.net with ESnet SMTP (PP); Fri, 1 Nov 1996 09:45:57 -0800 Received: by hill.msri.org (8.7/1.43r) id KAA00198; Fri, 1 Nov 1996 10:45:59 -0700 (PPET) From: dave@msri.org (Dave Wright) Received: from gauss.msri.org(198.129.65.58) by msri.org via smap (V1.3) id sma000194; Fri Nov 1 10:45:15 1996 Received: by gauss.msri.org (8.7/MSRI) id JAA04236; Fri, 1 Nov 1996 09:44:30 -0800 (PST) Message-Id: <199611011744.JAA04236@gauss.msri.org> Subject: Re: unsubscribe To: garcia@scranton.com (Joe Garcia) Date: Fri, 1 Nov 1996 09:44:30 -0800 (PST) Cc: rem-conf@es.net In-Reply-To: from "Joe Garcia" at Nov 1, 96 08:51:35 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit : : : this is my third attempt to unsubscribe. please facilitate ASAP! : : ---------- : unsubscribe : : http://www.msri.org/mbone/ml.html You can unsubscribe from the web page or send email to rem-conf-request@es.net From rem-conf-request@es.net Fri Nov 01 18:37:00 1996 Received: from hill.msri.org (actually msri.org) by osi-east.es.net with ESnet SMTP (PP); Fri, 1 Nov 1996 15:36:18 -0800 Received: by hill.msri.org for (8.7/1.43r) id QAA07641; Fri, 1 Nov 1996 16:36:20 -0700 (PPET) Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma007632; Fri Nov 1 16:35:37 1996 Received: by hille.msri.org (8.7/MSRI) id QAA08016; Fri, 1 Nov 1996 16:44:50 -0700 (PPET) Date: Fri, 1 Nov 1996 16:44:50 -0700 (PPET) Message-Id: <199611012344.QAA08016@hille.msri.org> From: ROWE Reply-to: ROWE@BMRC.Berkeley.EDU Subject: Two Short Talks: "Notes on VOD Networks" and "MPEG Audio Servers" MBone Broadcast Announcement ---------------------------- Title: Two Short Talks: "Notes on VOD Networks" and "MPEG Audio Servers" Date: Nov 06, 1996 Time: 12:30 PST8PDT 1.5 hours Contact: ROWE@BMRC.Berkeley.EDU URL: http://bmrc.berkeley.edu/298/w11.html Description: Notes on Video On Demand Networks." The author has worked on a number of real-world VOD and digital interactive video network projects including the Bell Atlantic Stargazer (tm) system. A quick technical survey of several systems is presented. "MPEG Audio Servers." While much attention has focused on video server design, an interesting related field is audio servers. While acceptance of MPEG video in commercial applications is slow, MPEG audio is increasingly being used over ISDN transport as a low cost high quality distribution mechanism for broadcast quality audio. The presenter will discuss the MPEG Audio market, applications, and the IMAKE ISDN Media Server. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Fri Nov 01 19:07:36 1996 Received: from bmrc.Berkeley.EDU by osi-east.es.net with ESnet SMTP (PP); Fri, 1 Nov 1996 16:07:05 -0800 Received: from nobozo.CS.Berkeley.EDU (nobozo.CS.Berkeley.EDU [128.32.34.58]) by bmrc.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id PAA16999 for <298-list@bmrc.Berkeley.EDU>; Fri, 1 Nov 1996 15:59:20 -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 PAA04397 for <298-list@bmrc>; Fri, 1 Nov 1996 15:59:20 -0800 Date: Fri, 1 Nov 1996 15:59:20 -0800 Message-Id: <199611012359.PAA04397@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 From: Jerrlyn Iwata Subject: Berkeley Multimedia & Graphics seminar Berkeley Multimedia and Graphics Seminar (Wednesday, November 6, 1996 12:30-2:00 PDT 405 Soda Hall) Two Short Talks: "Notes on Video On Demand Networks" and "MPEG Audio Servers" Sam Drake Imake "Notes on Video On Demand Networks." The author has worked on a number of real-world VOD and digital interactive video network projects including the Bell Atlantic Stargazer (tm) system. A quick technical survey of several systems is presented. "MPEG Audio Servers." While much attention has focused on video server design, an interesting related field is audio servers. While acceptance of MPEG video in commercial applications is slow, MPEG audio is increasingly being used over ISDN transport as a low cost high quality distribution mechanism for broadcast quality audio. The presenter will discuss the MPEG Audio market, applications, and the IMAKE ISDN Media Server. ================================================================================ This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12.40 PDT (GMT - 8 hrs). See sd 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 Nov 01 21:12:30 1996 Received: from proxy2.ba.best.com by osi-east.es.net with ESnet SMTP (PP); Fri, 1 Nov 1996 18:11:43 -0800 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy2.ba.best.com (8.7.6/8.7.3) with ESMTP id SAA05734 for ; Fri, 1 Nov 1996 18:10:59 -0800 (PST) Received: (prince@localhost) by shellx.best.com (8.6.12/8.6.5) id SAA04865 for rem-conf@es.net; Fri, 1 Nov 1996 18:10:38 -0800 Date: Fri, 1 Nov 1996 18:10:38 -0800 From: Vinay Kumar Message-Id: <199611020210.SAA04865@shellx.best.com> To: rem-conf@es.net Subject: Hypertext archives of this list are available Hypertext archives of this mailing list (and several other MBone-related lists) are now available on the MBone Information Web at http://www.mbone.com/lists/ The archives include postings as far back as we could obtain -- in one case, back to 1992! -- and they are automagically updated with new postings each day. BTW, the MBone Information Web has a new look and is generally being upgraded with new and updated materials. If you're currently referencing this site from another WWW site, please note that the current address is http://www.mbone.com/ and not older addresses like www.eit.com/techinfo/mbone.html or www.best.com/~prince/techinfo or other variations. We're trying to make sure that those old addresses continue to work, but can't promise to do that forever. Please check and update your site. Questions, suggestions, or comments: please send to webmaster@mbone.com Enjoy! From rem-conf-request@es.net Sun Nov 03 00:42:18 1996 Received: from nvsgi1.netvision.net.il by osi-east.es.net with ESnet SMTP (PP); Sat, 2 Nov 1996 21:41:38 -0800 Received: from gili-nt (ptt-testing.elron.net [199.203.124.48]) by nvsgi1.netvision.net.il (8.7.5/8.7.3) with SMTP id HAA00689 for ; Sun, 3 Nov 1996 07:41:12 +0200 (IST) Message-ID: <327C4D55.B35@elron.net> Date: Sun, 03 Nov 1996 07:44:21 +0000 From: Gili Torovezky Reply-To: gili@elron.net Organization: ArelNet X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi How to get off this list? email : gili@elron.net From rem-conf-request@es.net Sun Nov 03 00:57:33 1996 Received: from nvsgi1.netvision.net.il by osi-east.es.net with ESnet SMTP (PP); Sat, 2 Nov 1996 21:56:44 -0800 Received: from gili-nt (ptt-testing.elron.net [199.203.124.48]) by nvsgi1.netvision.net.il (8.7.5/8.7.3) with SMTP id HAA00869 for ; Sun, 3 Nov 1996 07:56:28 +0200 (IST) Message-ID: <327C50E9.30F1@elron.net> Date: Sun, 03 Nov 1996 07:59:37 +0000 From: Gili Torovezky Reply-To: gili@elron.net Organization: ArelNet X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe From rem-conf-request@es.net Sun Nov 03 09:47:28 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Sun, 3 Nov 1996 06:46:56 -0800 Received: from rat.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 3 Nov 1996 14:46:26 +0000 To: rem-conf@es.net, csd@netbox.com, jared@wolverine.hq.cic.net, Charles.A.Ross@cc.gettysburg.edu, G.B.Stringer@exeter.ac.uk Subject: RAT v3.0.3 Linux is available cc: ucl-audio@cs.ucl.ac.uk Date: Sun, 03 Nov 1996 14:46:26 +0000 Message-ID: <2400.847032386@cs.ucl.ac.uk> From: Colin Perkins RAT v3.0.3 is now available for Linux only from ftp://cs.ucl.ac.uk/mice/rat/ This is an experimental version of RAT. Some aspects of the program do not yet work, and many bugs remain. It has been tested on Linux 2.0.24 with a SoundBlaster compatible card running half-duplex only: If you manage to get it to run on other versions of Linux, or with other sound cards, please let us know and we'll compile a list of what works, and what doesn't. The purpose of this release is to test the Linux specific code: RAT v3.0.x for SunOS/Solaris/IRIX/Win32 will be made available in a few months, once a number of additional features have been implemented. Work is progressing on ports to HP-UX and FreeBSD, we will announce these at a later date. Send comments/suggestions/bug-reports to: rat-trap@cs.ucl.ac.uk -- Colin Perkins Email: c.perkins@cs.ucl.ac.uk Department of Computer Science Phone: (+44) 171 419 3666 University College London WWW : http://www.cs.ucl.ac.uk/staff/c.perkins/ From rem-conf-request@es.net Mon Nov 04 04:43:46 1996 Received: from mail.cs.tu-berlin.de by osi-east.es.net with ESnet SMTP (PP); Mon, 4 Nov 1996 01:43:01 -0800 Received: from peseta.cs.tu-berlin.de (effekta@peseta.cs.tu-berlin.de [130.149.20.44]) by mail.cs.tu-berlin.de (8.6.13/8.6.12) with ESMTP id KAA03682 for ; Mon, 4 Nov 1996 10:42:58 +0100 From: Thordis Krieger Received: (from effekta@localhost) by peseta.cs.tu-berlin.de (8.8.2/8.7.3) id KAA26216 for rem-conf@es.net; Mon, 4 Nov 1996 10:42:53 +0100 (MET) Message-Id: <199611040942.KAA26216@peseta.cs.tu-berlin.de> To: rem-conf@es.net Date: Mon, 4 Nov 1996 10:42:47 +0100 (MET) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII unsubscribe From rem-conf-request@es.net Mon Nov 04 12:51:08 1996 Received: from gilbert.ucc.hull.ac.uk by osi-east.es.net with ESnet SMTP (PP); Mon, 4 Nov 1996 09:50:20 -0800 Received: from mailhub.dcs.hull.ac.uk (actually host bertie.dcs.hull.ac.uk) by gilbert.ucc.hull.ac.uk with SMTP local (PP); Mon, 4 Nov 1996 15:21:28 +0000 Received: from scarlet.dcs.hull.ac.uk by mailhub.dcs.hull.ac.uk with esmtp (Smail3.1.93 #9) id m0vKQp9-0004DdC; Mon, 4 Nov 96 15:20:27 +0000 (GMT) From: "G.T.Stimson" Message-Id: <10014.199611041523@scarlet.dcs.hull.ac.uk> Subject: subscribe To: rem-conf@es.net Date: Mon, 4 Nov 1996 15:23:25 +0000 (GMT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit subscribe rem-conf Gary Stimson -- Department of Computer Science Tel: +44 (0)1482 465253 University of Hull Fax: +44 (0)1482 466666 Hull HU6 7RX E-Mail: g.t.stimson@dcs.hull.ac.uk From rem-conf-request@es.net Mon Nov 04 16:35:10 1996 Received: from ruebert.ieee.org by osi-east.es.net with ESnet SMTP (PP); Mon, 4 Nov 1996 13:34:32 -0800 Received: (from daemon@localhost) by ruebert.ieee.org (8.7.5/8.7.3) id QAA08429; Mon, 4 Nov 1996 16:36:45 -0500 (EST) Date: Mon, 4 Nov 1996 16:36:45 -0500 (EST) Message-Id: <199611042136.QAA08429@ruebert.ieee.org> To: rem-conf@es.net From: majordomo@majordomo.ieee.org Subject: Welcome to comsoc-conferences Reply-To: majordomo@majordomo.ieee.org Precedence: bulk Organization: IEEE Service Center, Piscataway, NJ -- Welcome to the comsoc-conferences mailing-list! If you ever want to remove yourself from this mailing list, send the following command in email to "majordomo@majordomo.ieee.org" with the following command in the body of your email message: unsubscribe comsoc-conferences rem-conf@es.net Here's the general information for the list you've subscribed to, in case you don't already have it: #### No info available for comsoc-conferences. From rem-conf-request@es.net Mon Nov 04 21:21:54 1996 Received: from cosmos (actually maple.kaist.ac.kr) by osi-east.es.net with ESnet SMTP (PP); Mon, 4 Nov 1996 18:21:21 -0800 Received: from tulip.kaist.ac.kr (tulip [143.248.185.12]) by cosmos (8.6.12h2/8.6.12) with ESMTP id LAA07201; Tue, 5 Nov 1996 11:20:03 +0900 Received: (from krkang@localhost) by tulip.kaist.ac.kr (8.6.12h2/8.6.12) id LAA11705; Tue, 5 Nov 1996 11:23:40 +0900 From: Kyungran Kang Message-Id: <199611050223.LAA11705@tulip.kaist.ac.kr> Subject: Micro Robot World Cup Soccer Tournament To: rem-conf@es.net Date: Tue, 5 Nov 1996 11:23:39 +0900 (KST) Cc: expo-all@expo.or.kr X-Mailer: ELM [version 2.4 PL21-h4] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 944 Micro Robot World-Cup Soccer Tournament'96 KAIST, Taejon, Korea 1996.11.9(Sat)-12(Tue) The First Micro-Robot World Cup Soccer Tournament (MIROSOT'96) is sponsored by the IEEE Robotics and Automation Society and supported by LG Semicon Co., Ltd. It is an international event of Internet Expo. MIROSOT'96 will provide a forum for professional robot engineers and researchers, to present the recent advances in research and development and also to compete with each other in a soccer tournament with a team of micro-robots equipped with highly advanced technologies. The games will be broadcast on MBone. There will be two sessions; live broadcast and recorded one which is for the receivers in North/South America and Europe. More detail information is available at http://www.mirosot.org. And session announcement will be made by sdr. I'm eagerly looking forward to your participation. Thanks in advance. Kyungran Kang From rem-conf-request@es.net Mon Nov 04 21:40:11 1996 Received: from ruebert.ieee.org by osi-east.es.net with ESnet SMTP (PP); Mon, 4 Nov 1996 18:39:33 -0800 Received: (from daemon@localhost) by ruebert.ieee.org (8.7.5/8.7.3) id VAA02474; Mon, 4 Nov 1996 21:41:56 -0500 (EST) Date: Mon, 4 Nov 1996 21:41:56 -0500 (EST) Message-Id: <199611050241.VAA02474@ruebert.ieee.org> To: rem-conf@es.net From: majordomo@majordomo.ieee.org Subject: Majordomo results: blee. Reply-To: majordomo@majordomo.ieee.org Precedence: bulk Organization: IEEE Service Center, Piscataway, NJ -- >>>> unsubscribe comsoc-conferences rem-conf@es.net **** unsubscribe: 'rem-conf@es.net' is not a member of list 'comsoc-conferences'. From rem-conf-request@es.net Tue Nov 05 16:38:50 1996 Received: from ruebert.ieee.org by osi-east.es.net with ESnet SMTP (PP); Tue, 5 Nov 1996 13:37:48 -0800 Received: (from root@localhost) by ruebert.ieee.org (8.7.5/8.7.3) id QAA13365; Tue, 5 Nov 1996 16:23:28 -0500 (EST) Date: Tue, 5 Nov 1996 16:23:28 -0500 (EST) Message-Id: <199611052123.QAA13365@ruebert.ieee.org> From: comsoc-mktg@ieee.org (Communications Society Marketing) To: rem-conf@es.net Subject: Apology regarding comsoc-conferences subscriptions Precedence: bulk X-Sender: postmaster@ieee.org X-LoopDetect: postmaster@ieee.org Organization: IEEE Communications Society Dear Communications Industry Professional, Please accept our apology for creating a list with your email address on it yesterday. In our attempts to make use of these exciting new technologies, our enthusiasm took us beyond our full understanding of the ramifications of what we were attempting. In a effort to fix the resulting problem, we have removed ALL addresses >from this list, including yours. If you are interested in learning about important upcoming IEEE Communications Society events, such as the dates, locations and paper submission details and deadlines, please follow the instructions below to subscribe to this list. In the coming months we will be sending short announcements to you with pointers to Internet locations. There you can get the information you want about IEEE Communications Society events, such as visiting our Conference Calendar listing at http://www.ieee.org/comsoc/confs/ where you can find details on communications industry conferences, workshops and symposia scheduled in the next two years. Again, we're sorry for the messages you received yesterday regarding this list and assure you that, unless YOU subscribe to it, you will not be on it. Thank you, Clark DesSoye, Marketing Manager, IEEE Communications Society Instructions for subscribing to the 'comsoc-conferences' Mailing-List: Simply send an E-Mail message to: majordomo@majordomo.ieee.org containing one of the following lines in the body: subscribe comsoc-conferences -or- subscribe comsoc-conferences e-mail_address The first format will subscribe YOUR e-mail address as it appears in the headers of your message. Use the 2nd format to subscribe an alternate address. From rem-conf-request@es.net Tue Nov 05 19:26:13 1996 Received: from broon.off.connect.com.au by osi-east.es.net with ESnet SMTP (PP); Tue, 5 Nov 1996 16:25:20 -0800 Received: from connect.com.au (ggm@localhost) by broon.off.connect.com.au with ESMTP id KAA15157 (8.7.5/IDA-1.6); Wed, 6 Nov 1996 10:24:47 +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: Mark Handley cc: rem-conf@es.net Subject: Re: New version of Sdr (2.3a1) and Sdr source available In-reply-to: Your message of "Fri, 01 Nov 1996 10:54:16 GMT." <17598.846845656@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Nov 1996 10:24:46 +1000 Message-ID: <15156.847239886@connect.com.au> From: George Michaelson 2.3a1 appears to have an off-by-one error selecting the private session to invite other participants. Anybody else seeing this? We're on Solaris 2.5.1 btw Also, I think that a prefs option to make it automatically start *your* clients when you do an invite which is accepted would make sense and remove the need to "join" yourself. Does it have a primitive directory option? mmcc's .mmccrc is flawed and doesn't scale but for inside-company use, its invaluable. I don't know the person@machine bindings for all the people I want to talk to! -George From rem-conf-request@es.net Wed Nov 06 05:22:22 1996 Received: from etamin.brunel.ac.uk by osi-east.es.net with ESnet SMTP (PP); Wed, 6 Nov 1996 02:20:30 -0800 Received: from babbage.brunel.ac.uk by etamin.brunel.ac.uk with SMTP (PP); Wed, 6 Nov 1996 10:18:25 +0000 From: Andrew.Findlay@brunel.ac.uk Message-Id: <25165.199611061018@babbage.brunel.ac.uk> Subject: Re: New version of Sdr ... (Directory Service wanted) To: ggm@connect.com.au (George Michaelson) Date: Wed, 6 Nov 1996 10:18:23 +0000 (GMT) Cc: rem-conf@es.net In-Reply-To: <15156.847239886@connect.com.au> from "George Michaelson" at Nov 6, 96 10:24:46 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1069 >Does it have a primitive directory option? mmcc's .mmccrc is flawed and doesn't >scale but for inside-company use, its invaluable. I don't know the >person@machine bindings for all the people I want to talk to! Directory integration is certainly important, but has been largely ignored up to now. You might be interested in my paper `The Multi-Media Telephone: Directory service and session control for multi-media communications', in which I propose a way to link several existing technologies and one (simple) new one to produce the sort of service you are asking for. The PostScript is available at: ftp://src.brunel.ac.uk/x500/multi-media-telephone.ps A revised version of this paper was published by the IEEE in the proceedings of SDNE 96. Andrew ---------------------------------------------------------------------------- | From Andrew Findlay at Brunel University, Uxbridge, UB8 3PH, UK | | Andrew.Findlay@brunel.ac.uk +44 1895 203066 or +44 1895 274000 x2512 | ---------------------------------------------------------------------------- From rem-conf-request@es.net Wed Nov 06 09:19:05 1996 Received: from mercury.lcs.mit.edu by osi-east.es.net with ESnet SMTP (PP); Wed, 6 Nov 1996 06:18:31 -0800 Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id JAA02851; Wed, 6 Nov 1996 09:18:25 -0500 X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: George Michaelson cc: rem-conf@es.net Subject: Re: New version of Sdr (2.3a1) and Sdr source available In-reply-to: Your message of "Wed, 06 Nov 96 10:24:46 +1000." <15156.847239886@connect.com.au> Date: Wed, 06 Nov 96 09:18:25 -0500 Message-ID: <2910.847289905@mercury.lcs.mit.edu> Sender: mjh@mercury.lcs.mit.edu X-Mts: smtp >Also, I think that a prefs option to make it automatically start *your* >clients when you do an invite which is accepted would make sense and remove >the need to "join" yourself. Yes, sounds like a good idea. >Does it have a primitive directory option? mmcc's .mmccrc is flawed and doesn' >t >scale but for inside-company use, its invaluable. I don't know the >person@machine bindings for all the people I want to talk to! I've delayed dong any more work on the invitation UI because Henning and I are talking about merging the SIP and SCIP proposals, and I was waiting to see how this turned out. However, in principle, neither SIP nor SCIP require you to know the actual host - both intend the use of proxies/relays to perform the final local location of the user. It's just that what's in sdr right now is a minimal subset of SIP fucntionality. Mark From rem-conf-request@es.net Wed Nov 06 10:35:34 1996 Received: from nfs1.inf.rl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Wed, 6 Nov 1996 07:35:03 -0800 Received: from grommit.cis.rl.ac.uk.informatics by nfs1.inf.rl.ac.uk (SMI-8.6/SMI-SVR4) id PAA02220; Wed, 6 Nov 1996 15:34:16 GMT Received: by grommit.cis.rl.ac.uk.informatics (SMI-8.6/SMI-SVR4) id PAA02845; Wed, 6 Nov 1996 15:34:14 GMT Date: Wed, 6 Nov 1996 15:34:14 GMT From: ijj@inf.rl.ac.uk (Ian Johnson) Message-Id: <199611061534.PAA02845@grommit.cis.rl.ac.uk.informatics> To: rem-conf@es.net, ggm@connect.com.au Subject: List problems in Sdr (2.3a1) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: WwlX73W64t9TCyS3ULdHng== George, I am also seeing problems selecting private sessions. In my case, with only one entry in the private session list, selecting the private session brings up session info for the first session in the "general" list. I haven't tried looking at the source yet - not sure if my Tcl's up to it. I agree with your ideas on the invite procedure as well. BTW How's that young Danny Smith doing? Has marriage changed him?> -- "Nudist welfare man's wife fell for Chinese hypnotist >from the Co-Op bacon counter" - News of the World headline Ian Johnson Internet: ijj@inf.rl.ac.uk CLRC Rutherford Appleton Laboratory, World-Wide Web: Chilton, Didcot, Oxon OX11 0QX. http://www.cis.rl.ac.uk/people/ijj.html From rem-conf-request@es.net Thu Nov 07 08:46:08 1996 Received: from cosmos (actually maple.kaist.ac.kr) by osi-east.es.net with ESnet SMTP (PP); Thu, 7 Nov 1996 05:45:26 -0800 Received: from tulip.kaist.ac.kr (tulip [143.248.185.12]) by cosmos (8.6.12h2/8.6.12) with ESMTP id WAA21369 for ; Thu, 7 Nov 1996 22:44:11 +0900 Received: (from krkang@localhost) by tulip.kaist.ac.kr (8.6.12h2/8.6.12) id WAA01364 for rem-conf@es.net; Thu, 7 Nov 1996 22:47:49 +0900 From: Kyungran Kang Message-Id: <199611071347.WAA01364@tulip.kaist.ac.kr> Subject: Korean Traditional Persecution Quarter To: rem-conf@es.net Date: Thu, 7 Nov 1996 22:47:48 +0900 (KST) X-Mailer: ELM [version 2.4 PL21-h4] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 492 Hello. Have you ever heard about "Samulnori", korean traditional persecution Quarter. We korean are very proud of "Samulnori". In Chonju, a city of Korea, there is an communication exhibition. As the opening event of the exhibition, "Samulnori" will be played. It wil be a great experience to enjoy "Samulnori" on the Internet. It begins at 01:30 GMT on November 8(this Friday). Don't miss the chance. I'm eagerly looking forward to your participation. Thanks in advance Kyungran Kang From rem-conf-request@es.net Thu Nov 07 11:42:17 1996 Received: from emout16.mail.aol.com (actually emout16.mx.aol.com) by osi-east.es.net with ESnet SMTP (PP); Thu, 7 Nov 1996 08:41:34 -0800 Received: by emout16.mail.aol.com (8.6.12/8.6.12) id LAA08616 for rem-conf@es.net; Thu, 7 Nov 1996 11:41:01 -0500 Date: Thu, 7 Nov 1996 11:41:01 -0500 From: FredHous@aol.com Message-ID: <961107114059_1847762230@emout16.mail.aol.com> To: rem-conf@es.net Subject: Fwd: unsubscribe THIS IS MY FOURTH REQUEST. PLEASE REMOVE ME FROM YOUR LIST. --------------------- Forwarded message: From: gili@elron.net (Gili Torovezky) Reply-to: gili@elron.net To: rem-conf@es.net Date: 96-11-03 00:51:24 EST Hi How to get off this list? email : gili@elron.net From rem-conf-request@es.net Thu Nov 07 13:00:52 1996 Received: from one.net (actually mail.one.net) by osi-east.es.net with ESnet SMTP (PP); Thu, 7 Nov 1996 09:59:43 -0800 Received: from default (port-12-11.access.one.net [206.112.194.111]) by one.net (8.8.2/8.7.5) with ESMTP id MAA31047 for ; Thu, 7 Nov 1996 12:59:38 -0500 Message-Id: <199611071759.MAA31047@one.net> From: Geoffrey Stewart Nimmo To: rem-conf Subject: unsubscribe Date: Thu, 7 Nov 1996 12:59:34 -0500 X-MSMail-Priority: High X-Priority: 1 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit unsubscribe Geoffrey Nimmo nextwave@one.net From rem-conf-request@es.net Thu Nov 07 15:08:15 1996 Received: from gatekeeper.sprintlabs.com (actually dmz.sprintlabs.com) by osi-east.es.net with ESnet SMTP (PP); Thu, 7 Nov 1996 12:07:08 -0800 Received: by gatekeeper.sprintlabs.com id AA19796 (5.67b/IDA-1.5 for ); Thu, 7 Nov 1996 12:09:52 -0800 Message-Id: <199611072009.AA19796@gatekeeper.sprintlabs.com> Received: from unknown(199.2.53.28) by gatekeeper.sprintlabs.com via smap (V3.1) id xma019791; Thu, 7 Nov 96 12:09:38 -0800 X-Sender: aollikai@gatekeeper Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 7 Nov 1996 12:11:35 -0700 To: FredHous@aol.com, gili@elron.net From: ari@sprintlabs.com (Ari Ollikainen) Subject: Re: Fwd: unsubscribe Cc: rem-conf@es.net >THIS IS MY FOURTH REQUEST. PLEASE REMOVE ME FROM YOUR LIST. >--------------------- >Forwarded message: >From: gili@elron.net (Gili Torovezky) >Reply-to: gili@elron.net >To: rem-conf@es.net >Date: 96-11-03 00:51:24 EST > >Hi >How to get off this list? >email : gili@elron.net You and all other frantic unsubscribers could try to do it the right way...by sending your UNSUBSCRIBE request to: rem-conf-request@es.net The list maintainers do NOT read the messages sent to the list. Back when I ran/maintained this list, I used to post a periodic reminder for change requests and archive(s) location...I also studiously ignored drop requests sent to the whole list unless I had some time available to service them. Please do NOT send me any requests for changes...I've moved on... _/_/ _/_/_/_/ _/ Ari Ollikainen _/ _/ _/ _/ _/ Sprint Advanced Technology Laboratories _/_/_/_/ _/_/_/_/ _/ 1 Adrian Court (M/S: CABURS0102) _/ _/ _/ _/ _/ Burlingame, CA 94010 _/ _/ _/ _/ _/ Voice: 415 375 4265 FAX: 415 375 4490 ~~RECOM Technologies Inc.~~ From rem-conf-request@es.net Thu Nov 07 16:39:55 1996 Received: from hill.msri.org (actually msri.org) by osi-east.es.net with ESnet SMTP (PP); Thu, 7 Nov 1996 13:38:46 -0800 Received: by hill.msri.org for (8.7/1.43r) id NAA12055; Thu, 7 Nov 1996 13:38:47 -0800 (PST) Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma012018; Thu Nov 7 13:37:51 1996 Received: by hille.msri.org (8.7/MSRI) id OAA04278; Thu, 7 Nov 1996 14:46:48 -0700 (PPET) Date: Thu, 7 Nov 1996 14:46:48 -0700 (PPET) Message-Id: <199611072146.OAA04278@hille.msri.org> From: ROWE Reply-to: ROWE@BMRC.Berkeley.EDU Subject: "Policy Implications of Technological Protection for Digital Content" MBone Broadcast Announcement ---------------------------- Title: "Policy Implications of Technological Protection for Digital Content" Date: Nov 13, 1996 Time: 12:30 PST8PDT 1.5 hours Contact: ROWE@BMRC.Berkeley.EDU URL: http://BMRC.Berkeley.EDU/298/w12.html Description: Using technologies to protect copyrighted works in digital form is likely to mean that content owners will have less need to call upon the law to protect their "crown jewels." Technology alone, however, may not provide all the protection that content owners may need, since what one technology can do, another can undo. New legal rules to regulate technologies capable of circumventing technological protection have been proposed at national and international levels. While some regulation of circumvention technologies may be appropriate, current proposals are ill-defined and overbroad. More thought should be given to the broader policy implications of these technologies and proposed regulations to shore up technological fences. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Thu Nov 07 16:40:29 1996 Received: from hill.msri.org (actually msri.org) by osi-east.es.net with ESnet SMTP (PP); Thu, 7 Nov 1996 13:38:46 -0800 Received: by hill.msri.org for (8.7/1.43r) id NAA12057; Thu, 7 Nov 1996 13:38:48 -0800 (PST) Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma012019; Thu Nov 7 13:37:52 1996 Received: by hille.msri.org (8.7/MSRI) id OAA04281; Thu, 7 Nov 1996 14:47:01 -0700 (PPET) Date: Thu, 7 Nov 1996 14:47:01 -0700 (PPET) Message-Id: <199611072147.OAA04281@hille.msri.org> From: ROWE Reply-to: ROWE@BMRC.Berkeley.EDU Subject: "Policy Implications of Technological Protection for Digital Content" MBone Broadcast Announcement ---------------------------- Title: "Policy Implications of Technological Protection for Digital Content" Date: Nov 13, 1996 Time: 12:30 PST8PDT 1.5 hours Contact: ROWE@BMRC.Berkeley.EDU URL: http://BMRC.Berkeley.EDU/298/w12.html Description: Using technologies to protect copyrighted works in digital form is likely to mean that content owners will have less need to call upon the law to protect their "crown jewels." Technology alone, however, may not provide all the protection that content owners may need, since what one technology can do, another can undo. New legal rules to regulate technologies capable of circumventing technological protection have been proposed at national and international levels. While some regulation of circumvention technologies may be appropriate, current proposals are ill-defined and overbroad. More thought should be given to the broader policy implications of these technologies and proposed regulations to shore up technological fences. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Thu Nov 07 16:53:41 1996 Received: from bmrc.Berkeley.EDU by osi-east.es.net with ESnet SMTP (PP); Thu, 7 Nov 1996 13:52:41 -0800 Received: from nobozo.CS.Berkeley.EDU (nobozo.CS.Berkeley.EDU [128.32.34.58]) by bmrc.Berkeley.EDU (8.8.2/8.6.9) with SMTP id NAA22777 for <298-list@BMRC.Berkeley.EDU>; Thu, 7 Nov 1996 13:43:30 -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 NAA16171 for <298-list@BMRC>; Thu, 7 Nov 1996 13:43:31 -0800 Date: Thu, 7 Nov 1996 13:43:31 -0800 Message-Id: <199611072143.NAA16171@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 From: Jerrlyn Iwata Subject: Berkeley Multimedia & Graphics Seminar Berkeley Multimedia and Graphics Seminar (Wednesday November 13, 1996 12:30-2:00 PDT 405 Soda Hall) "Policy Implications of Technological Protection for Digital Content" Pamela Samuelson University of California at Berkeley Using technologies to protect copyrighted works in digital form is likely to mean that content owners will have less need to call upon the law to protect their "crown jewels." Technology alone, however, may not provide all the protection that content owners may need, since what one technology can do, another can undo. New legal rules to regulate technologies capable of circumventing technological protection have been proposed at national and international levels. While some regulation of circumvention technologies may be appropriate, current proposals are ill-defined and overbroad. More thought should be given to the broader policy implications of these technologies and proposed regulations to shore up technological fences. -------------------------------------------------------------------------------- This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40 PDT (GMT - 8 hrs). See sd or http://bmrc.berkeley.edu/298 for instructions on setting up, connecting to, and operating the MBONE tools. Please direct questions to davesimp@cs.berkeley.edu. From rem-conf-request@es.net Fri Nov 08 07:45:18 1996 Received: from www45.inria.fr by osi-east.es.net with ESnet SMTP (PP); Fri, 8 Nov 1996 04:43:34 -0800 Received: by www45.inria.fr (8.7.6/8.6.12) id NAA21194; Fri, 8 Nov 1996 13:40:51 +0100 (MET) Message-Id: <199611081240.NAA21194@www45.inria.fr> To: rem-conf@es.net From: Philipp Hoschka Subject: confused about admin scoped multicast addresses Date: Fri, 08 Nov 1996 13:40:49 +0100 Sender: Philipp.Hoschka@sophia.inria.fr What is the status of admin scoped multicast addresses ? Has this block of addresses been officially reserved, or is it only a proposal that has been around for more than two years now ? My impression was the former, but I cannot see any trace of admin scoped addresses in the relevenat IANA document (ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses) Btw, I know that this is not really a rem-conf issue, but I don't want to have to subscribe to the mbone list only for asking this question. -Philipp Hoschka ---------------------------------------------------------------------- Philipp Hoschka WWW: http://www.inria.fr/rodeo/personnel/hoschka/hoschka.html | INRIA - WWW Consortium hoschka@sophia.inria.fr | 2004, Route des Lucioles, BP 93 Tel:(+33) 93 65 79 84 | 06902 Sophia Antipolis Cedex Fax:(+33) 93 65 77 65 | France ---------------------------------------------------------------------- From rem-conf-request@es.net Fri Nov 08 12:12:51 1996 Received: from wayback.uoregon.edu by osi-east.es.net with ESnet SMTP (PP); Fri, 8 Nov 1996 09:12:11 -0800 Received: (from meyer@localhost) by wayback.uoregon.edu (8.8.0/8.7.3) id JAA12493; Fri, 8 Nov 1996 09:11:57 -0800 (PST) Date: Fri, 8 Nov 1996 09:11:57 -0800 (PST) Message-Id: <199611081711.JAA12493@wayback.uoregon.edu> From: "David M. Meyer 541/346-1747" To: Philipp Hoschka cc: rem-conf@es.net Subject: Re: confused about admin scoped multicast addresses Philipp, As far as I can tell, IANA hasn't formally assigned the admin space. draft-ietf-mboned-admin-ip-space-00.txt defines the requirements and asks IANA to allocate the the space. Dave From rem-conf-request@es.net Fri Nov 08 13:25:48 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Fri, 8 Nov 1996 10:25:02 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA14024; Fri, 8 Nov 1996 10:25:00 -0800 Date: Fri, 8 Nov 1996 10:25:00 -0800 (PST) From: Stephen Casner To: rem-conf@es.net Subject: AVT meeting at San Jose IETF Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Some people have asked me whether there will be a meeting of the Audio/Video Transport working group at IETF in San Jose next month. Yes, I requested two sessions for AVT. For those who did not see the message from our Area co-Director Allison Mankin some weeks ago, the reason AVT is not listed on the draft IETF agenda is that the Transport Area track is scheduled separately by the A.D. and then entered onto the agenda at once. I can understand the confusion this may cause, and I suggest that a note be added the draft agenda listing those groups that will be meeting but are not yet scheduled. On the off chance that you were unsure about attending because you didn't think AVT would meet, please note that today is the cutoff for early registration for IETF. In any case, it is time to put together the agenda for the AVT sessions, so I hereby solicit suggestions for topics to be discussed. Among the items on my list are: - transport aspects of the RTSP proposal and interaction with RTP - scaling of RTCP to large groups, esp. for "broadcast" - compressed RTP, for which I will send an updated draft soon - an update on H.263 payload format - moving the RTP spec to Draft Standard status Please let me know about other requests/suggestions you may have. -- Steve From rem-conf-request@es.net Fri Nov 08 16:04:19 1996 Received: from MVS.OAC.UCLA.EDU by osi-east.es.net with ESnet SMTP (PP); Fri, 8 Nov 1996 13:03:45 -0800 Received: from UCLAMVS.BITNET by MVS.OAC.UCLA.EDU (IBM MVS SMTP V2R2.1) with BSMTP id 2667; Fri, 08 Nov 96 13:03:47 PST Date: Fri, 08 Nov 96 13:03 PST To: rem-conf@ES.NET From: Denis DeLaRoca (310) 825-4580 Subject: sdr: expected network IN, got 16327 Session announcements apparently from imsl.ic.ornl.gov are making SDR log the above warning messages. -- Denis From rem-conf-request@es.net Fri Nov 08 22:07:47 1996 Received: from catarina.usc.edu by osi-east.es.net with ESnet SMTP (PP); Fri, 8 Nov 1996 19:07:15 -0800 Received: from excalibur.usc.edu (excalibur.usc.edu [128.125.51.11]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id TAA06369; Fri, 8 Nov 1996 19:06:39 -0800 Received: (ahelmy@localhost) by excalibur.usc.edu (8.6.10/8.6.9) id TAA05304; Fri, 8 Nov 1996 19:07:26 -0800 Date: Fri, 8 Nov 1996 19:07:26 -0800 (PST) From: Ahmed A-G Helmy To: Stephen Casner cc: rem-conf@es.net Subject: Re: AVT meeting at San Jose IETF In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII is the complete agenda for ietf San Jose currently available anywhere thanks -Ahmed > Some people have asked me whether there will be a meeting of the > Audio/Video Transport working group at IETF in San Jose next month. > > Yes, I requested two sessions for AVT. For those who did not see the > message from our Area co-Director Allison Mankin some weeks ago, the > reason AVT is not listed on the draft IETF agenda is that the > Transport Area track is scheduled separately by the A.D. and then > entered onto the agenda at once. I can understand the confusion this > may cause, and I suggest that a note be added the draft agenda listing > those groups that will be meeting but are not yet scheduled. > > On the off chance that you were unsure about attending because you > didn't think AVT would meet, please note that today is the cutoff for > early registration for IETF. > > In any case, it is time to put together the agenda for the AVT > sessions, so I hereby solicit suggestions for topics to be discussed. > Among the items on my list are: > > - transport aspects of the RTSP proposal and interaction with RTP > > - scaling of RTCP to large groups, esp. for "broadcast" > > - compressed RTP, for which I will send an updated draft soon > > - an update on H.263 payload format > > - moving the RTP spec to Draft Standard status > > Please let me know about other requests/suggestions you may have. > > -- Steve > > From rem-conf-request@es.net Sat Nov 09 17:27:58 1996 Received: from cosmos (actually maple.kaist.ac.kr) by osi-east.es.net with ESnet SMTP (PP); Sat, 9 Nov 1996 14:27:25 -0800 Received: (from krkang@localhost) by cosmos (8.6.12h2/8.6.12) id HAA17579; Sun, 10 Nov 1996 07:26:06 +0900 From: Kyungran Kang Message-Id: <199611092226.HAA17579@cosmos> Subject: recorded MIROSOT'96 on MBone To: rem-conf@es.net Date: Sun, 10 Nov 1996 07:26:05 +0900 (KST) Cc: mbone@isi.edu X-Mailer: ELM [version 2.4 PL21-h4] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 1039 Hello. Micro Robot World Cup Soccer Tournament(MIROSOT) has started at 5:00 GMT on Novermber 9. It was recorded and it is broadcast on MBone. Other remaining programs will be recorded and broadcast on MBone. You can see detailed information on sdr. It's title is "(Recorded) Micro Robot World Cup Soccer Tournament". Time schedule is following. It is GMT version. Have good time with MIROSOT on MBone. November 9 22:00-22:30 GMT Opening Ceremony 22:30-23:30 Dr.Norman Caplan "Robotics Research Education and Goverment Policy" 23:30-02:30 Preliminary Game November 10 22:00-23:00 Prof.Tzyh-Jong Tarn "Human/Machine Sharing Control for Intelligent Mechatronic Systems" 23:00-02:30 Preliminary Game November 11 22:00-23:30 Dr.John L. Casti "Would-Be Worlds;The Science and the Surprise of Artificial Worlds" 23:00-02:30 Main Game November 12 22:00-23:30 Dr.Lawrence J. Fogel "Top-down Evolutionary Engineering" 23:00-02:30 Semi-final Game, Final Game 23:00-03:30 Prize Award Kyungran Kang From rem-conf-request@es.net Sun Nov 10 22:36:19 1996 Received: from alpha.xerox.com by osi-east.es.net with ESnet SMTP (PP); Sun, 10 Nov 1996 19:35:48 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14478(5)>; Sun, 10 Nov 1996 19:35:32 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177557>; Sun, 10 Nov 1996 19:35:21 -0800 To: Denis DeLaRoca 825-4580 (310) cc: rem-conf@es.net Subject: Re: sdr: expected network IN, got 16327 In-reply-to: Your message of "Fri, 08 Nov 96 13:03:00 PST." <96Nov8.150947pst."18640(7)"@alpha.xerox.com> Date: Sun, 10 Nov 1996 19:35:09 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <96Nov10.193521pst.177557@crevenia.parc.xerox.com> In message <96Nov8.150947pst."18640(7)"@alpha.xerox.com> you write: >Session announcements apparently from imsl.ic.ornl.gov are making >SDR log the above warning messages. This is caused by White Pine's new version of CUSeeMe. It sends out badly malformed SDP packets way too often. I contacted White Pine about it when I discovered this behavior in a beta version but the product was already in boxes by then. My comments have been sent to the engineers for evaluation. If you upgrade to sdr v2.3a1, it will not complain about these malformed announcements. Bill From rem-conf-request@es.net Mon Nov 11 07:59:35 1996 Received: from matilda.wpine.com by osi-east.es.net with ESnet SMTP (PP); Mon, 11 Nov 1996 04:58:48 -0800 Received: from visual.wpine.com ([192.80.72.33]) by matilda.wpine.com (post.office MTA v2.0 0813 ID# 0-13495) with SMTP id AAA18068; Mon, 11 Nov 1996 07:58:01 -0500 Received: from boggs.wpine.com.wpine.com by visual.wpine.com (8.6.9/VM-941107.1) id IAA02894; Mon, 11 Nov 1996 08:01:14 -0500 Received: by boggs.wpine.com.wpine.com (4.1/VN941029.1) id AA02804; Mon, 11 Nov 96 07:46:36 EST Message-Id: <9611111246.AA02804@boggs.wpine.com.wpine.com> To: Bill Fenner Cc: Denis DeLaRoca 825-4580 (310) , rem-conf@es.net, boshea@wpine.com Subject: Re: sdr: expected network IN, got 16327 In-Reply-To: Your message of "Sun, 10 Nov 1996 19:35:09 PST." <96Nov10.193521pst.177557@crevenia.parc.xerox.com> Date: Mon, 11 Nov 1996 07:46:30 -0500 From: Brian O'Shea > >In message <96Nov8.150947pst."18640(7)"@alpha.xerox.com> you write: >>Session announcements apparently from imsl.ic.ornl.gov are making >>SDR log the above warning messages. > >This is caused by White Pine's new version of CUSeeMe. It sends out >badly malformed SDP packets way too often. I contacted White Pine >about it when I discovered this behavior in a beta version but the >product was already in boxes by then. My comments have been sent to >the engineers for evaluation. And we have seen the errors of our ways. The 2.1.1 version of the Enhanced CU-SeeMe incorporates your suggested changes to the SDP packets. >If you upgrade to sdr v2.3a1, it will not complain about these malformed >announcements. And when the 2.1.1 version of Enhanced CU-SeeMe becomes available, it is the one that you should use to do multicasting with. > > Bill -bos +***********************************************************************+ + Brian O'Shea White Pine Software + + Reflector Group Leader 542 Amherst St + + bos@wpine.com Nashua NH, 03063 + + Phone: 603-886-9050 Fax: 603-886-9051 + + All it takes is all you've got. + +***********************************************************************+ From rem-conf-request@es.net Mon Nov 11 13:32:03 1996 Received: from nobozo.CS.Berkeley.EDU by osi-east.es.net with ESnet SMTP (PP); Mon, 11 Nov 1996 10:31: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 KAA03045 for ; Mon, 11 Nov 1996 10:31:28 -0800 Date: Mon, 11 Nov 1996 10:31:28 -0800 Message-Id: <199611111831.KAA03045@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 November 13, 1996 12:30-2:00 PDT 405 Soda Hall) "Policy Implications of Technological Protection for Digital Content" Pamela Samuelson University of California at Berkeley MBONE BROADCAST BEGINS AT 12.40 PDT (GMT - 8 HOURS) From rem-conf-request@es.net Mon Nov 11 20:33:12 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Mon, 11 Nov 1996 17:32:32 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA19749; Mon, 11 Nov 1996 17:31:32 -0800 Date: Mon, 11 Nov 1996 17:31:32 -0800 (PST) From: Stephen Casner To: rem-conf@es.net Subject: 37th IETF SAN JOSE: AVT Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The two Audio/Video Transport working group sessions have been scheduled as follows: Tuesday, December 10 at 1530 (opposite rip, ftpext, 6bone-bof, NMarea, ipsec, avt, ion) Wednesday, December 11at 1930 (frnetmib, acap, rwhois, dhc, disman, iab, mobileip) -- Steve From rem-conf-request@es.net Mon Nov 11 21:51:50 1996 Received: from cosmos (actually maple.kaist.ac.kr) by osi-east.es.net with ESnet SMTP (PP); Mon, 11 Nov 1996 18:51:20 -0800 Received: from miro.kaist.ac.kr (miro [203.232.77.2]) by cosmos (8.6.12h2/8.6.12) with ESMTP id LAA05742; Tue, 12 Nov 1996 11:49:30 +0900 Received: (from root@localhost) by miro.kaist.ac.kr (8.7.6/8.7.3) id LAA00441; Tue, 12 Nov 1996 11:50:20 +0900 (KST) From: Ran Root Message-Id: <199611120250.LAA00441@miro.kaist.ac.kr> Subject: MIROSOT'96 Final Game Today To: rem-conf@es.net Date: Tue, 12 Nov 1996 11:50:20 +0900 (KST) Cc: mbone-kr@knc.or.kr X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello. It is the final day of MIROSOT'96 today(November 12). MIROSOT'96 is being held in KAIST, Taejon, Korea. Semi-final games and final game will be broadcast on MBone from 06:00 GMT (15:00 KST) on November 12. The schedule is like following; MIROSOT Semi-final Games Soty(Korea) v.s. Mr.Gon(International Joint) Miro(Korea) v.s. Newton(USA) S-MIRO Semi-final Game Lami(Swiss) v.s. DRS(University of Davis, USA) MIROSOT Determine 3,4 S-MIRO Final Game ?? v.s. CM University(USA) MIROSOT Final Game Semi-final games and final game will be rebroadcast from 22:00 GMT. It will be great experience to enjoy soccer games on the Internet. You can get more information from sdr and from http://www.mirosot.org. I'm looking forward to your participation. Thanks in advance. Sincerely, Kyungran Kang From rem-conf-request@es.net Mon Nov 11 22:11:43 1996 Received: from miro.kaist.ac.kr (actually 203.232.77.4) by osi-east.es.net with ESnet SMTP (PP); Mon, 11 Nov 1996 19:11:06 -0800 Received: (from guest@localhost) by miro.kaist.ac.kr (8.6.12h2/8.6.9) id MAA01526; Tue, 12 Nov 1996 12:05:59 +0900 From: guest@miro.kaist.ac.kr Message-Id: <199611120305.MAA01526@miro.kaist.ac.kr> Subject: November 12 ; MIROSOT'96 final day To: rem-conf@es.net Date: Tue, 12 Nov 1996 12:05:58 +0900 (KST) Cc: mbone-kr@knc.or.kr X-Mailer: ELM [version 2.4 PL21-h4] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 789 Hello. November 12, it is the final day of MIROSOT'96. MIROSOT is Micro Robot Soccer Tournament. It is being held in KAIST, Taejon, Korea. It will be broadcast on MBone from 6:00 GMT(15:00 KST). The schedule is like following; MIROSOT Semi-final Games Soty(KAIST, Korea) v.s. Mr.Gon(International Joint) Miro(KAIST, Korea) v.s. Newton(USA) S-MIROSOT Semi-final Game DRS(University of Davis, USA) v.s. Lami(Swiss) MIROSOT Determine 3.4 S-MIROSOT Final Game MIROSOT Final Game It will be great experience to enjoy soccer game on the Internet. The semi-final games and final game will be rebroadcast from 22:00 GMT. More information is available in sdr and http://www.mirosot.org. We're eagerly looking forward to your participation. Thanks in advance. Sincerely, Kyungran Kang From rem-conf-request@es.net Mon Nov 11 23:39:15 1996 Received: from cosmos (actually maple.kaist.ac.kr) by osi-east.es.net with ESnet SMTP (PP); Mon, 11 Nov 1996 20:38:05 -0800 Received: (from krkang@localhost) by cosmos (8.6.12h2/8.6.12) id NAA06981; Tue, 12 Nov 1996 13:36:31 +0900 From: Kyungran Kang Message-Id: <199611120436.NAA06981@cosmos> Subject: MIROSOT'96 final day To: rem-conf@es.net Date: Tue, 12 Nov 1996 13:36:30 +0900 (KST) Cc: mbone-kr@knc.or.kr X-Mailer: ELM [version 2.4 PL21-h4] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 764 Hello. MIROSOT is World Cup Micro Robot Soccer Tournament. It is being held in KAIST, Taejon, Korea. November 12, today is the final day of MIROSOT'96. There will be semi-final games and final game. It will be broadcast on MBone from 06:00 GMT. The schedule is like following; MIROSOT semifinal games Soty(KAIST, Korea) v.s. Mr.Gon(International Joint) Miro(KAIST, Korea) v.s. Newton(USA) S-MIROSOT semifinal game DRS(University of California,Davis, USA) v.s. Lami(Swiss) MIROSOT determine 3,4 S-MIROSOT final game MIROSOT final game The semi final games and the final game will be rebroadcast from 22:00 GMT. It will be great experience to enjoy soccer games on the Internet. Thanks for your interest and participation. Sincerely, Kyungran Kang From rem-conf-request@es.net Tue Nov 12 01:30:37 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Mon, 11 Nov 1996 22:29:47 -0800 Received: from port4.precept.com by precept.com (5.x/SMI-4.1) id AA20220; Mon, 11 Nov 1996 22:29:18 -0800 Date: Mon, 11 Nov 1996 23:39:17 -0800 (PST) From: Stephen Casner To: Stan Naudus Cc: rem-conf@es.net Subject: Re: Coding RTCP packets with multiple streams. In-Reply-To: <274bc830@usrva.com> Message-Id: X-X-Sender: casner@little-bear.precept.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 28 Oct 1996, Stan Naudus wrote: > While this is defined very clearly in RFC1889 I have several > questions about how to code RTCP SR and RR packets in situations where > there are multiple streams in a single session. These questions are: > > 1.) In section 6.3.1 of RFC1889 (Page #22) it shows the sender > report (SR), and it seems from the figure and previous text that the > RTCP packet can only hold one streams sender report. How should > sessions with two or more streams have there SR RTCPs coded? I presume you are talking about a case where a single host is sending multiple streams (each with a different SSRC id) on the same RTP session. An example might be two video cameras. Each SR can only report about one SSRC id, but you can stack multiple individual SR packets, usually along with SDES CNAME packets as well, into one compound RTCP packet that goes in one UDP packet (or other lower-level protocol). > 2.) In section 6.3..2 of RFC1889 (Page #27) it shows the receiver > report (RR), and likewise it seems from the figure that a receiver > report RTCP packet can only be from one stream. If there are two > streams in the session that a RTCP RR is being reported on (both have > sent no information) how would this be coded? When a receiver hears multiple sources in an RTP session, it can report on up to 31 of them in a single RR packet because multiple "report blocks" can be packed together. The RR reports on the reception experienced by one RTP participant using the SSRC id of that participant. In the case of the sender above with two cameras, RRs might be issued with only one of those SSRC ids and not at all for the other since you might consider that the participant is listening only once. -- Steve From rem-conf-request@es.net Tue Nov 12 06:24:43 1996 Received: from gw.navio.com by osi-east.es.net with ESnet SMTP (PP); Tue, 12 Nov 1996 03:24:11 -0800 Received: (from proxy@localhost) by gw.navio.com (8.6.12/8.6.9) id DAA32417; Tue, 12 Nov 1996 03:23:52 -0800 Received: from lulu.navio.com(204.182.38.230) by tvsoft.com via smap (V1.3) id sma032412; Tue Nov 12 03:23:40 1996 Message-Id: <3.0b36.32.19961112032241.007789e8@gw.navio.com> X-Sender: brianb@gw.navio.com X-Mailer: Windows Eudora Pro Version 3.0b36 (32) Date: Tue, 12 Nov 1996 03:22:42 -0800 To: rem-conf@es.net, Stephen Casner From: Brian Bulkowski Subject: RTCP RR's Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Since someone else asked a bits-and-bytes protocol question here, I'll ask mine. This is about RR's. First, it appears that each client has to keep track of the SSRCs of all other clients in order to be able to judge the rate at which to send out RRs, and the time of the last RR they heard from that client. This would mean that the memory requirement would scale linearly with the number of listeners. In a cable TV system there may easily be 250,000 clients tuned in, each of which would need about 10 bytes per other receiver, thus requiring 2.5MB of memory just to keep track of the receiver SSRCs. The cable TV boxes in these cases rarely have more than 512K of memory, the new ones as high as 2MB (that's for the OS, the application, fonts, cache and frame buffer, and no VM), so this is flat-out impossible. So how do you decide how to rate out RR packets if you can't keep track of the SSRCs of all other clients? Pick a really small number; one packet per hour? Second is that cable systems are highly asymetric. You might easily have a 3Mbit/sec downlink, and a shared 9600 baud slotted aloha uplink. Given the guidelines in RFC 1889, the RTCP RR packets would overwhelm the uplink, and congest it into the ground in short order. In fact, the algorythms specified tend towards congestion. As the uplink congests, clients would decide that there are fewer other clients around, and attempt to send more packets, thus congesting the link further. There are a number of other pathological-to-RTCP networks that have already been built. I haven't even started with satellite systems. Remember further that as a client, you might not be able to detect that you are on one of these networks. In the case of a low-end PC on a cable modem, the PC is on 10Mb/sec ethernet, and the cable modem is effectivly an ethernet<->broadband bridge. On these networks there is no extra software on the PC side: it thinks it runs regular ethernet, it runs regular WinSock, CU-CMe, whatever. The cable modem companies can't use the serial port (too slow for the downlink), and don't want to build PC cards, especially when ISA ethernet cards are running $30. I think @Home's trials are using beefier uplinks, and PCs do have VM and hard drives, but the problems still exist. Thus, does every RTP implementation need to have user-setable parameters for the percentage of the downlink and using different algorythms for RR packet send rating? Shouldn't this be spec'd? How can we trust the user to tweak this parameter, since the code can't adjust itself, and the results of a mistake are disasterous: congestion collapse? Or is there something fundamental that I'm missing about RR packets? Please enlighten. Cheers, -brianb brian bulkowski Technical Project Lead, Navio Communications brianb@navio.com, brian@bulkowski.org From rem-conf-request@es.net Tue Nov 12 13:26:41 1996 Received: from seawind.bellcore.com by osi-east.es.net with ESnet SMTP (PP); Tue, 12 Nov 1996 10:25:45 -0800 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id NAA10338; Tue, 12 Nov 1996 13:25:10 -0500 Date: Tue, 12 Nov 1996 13:25:10 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9611121325.ZM10336@seawind.bellcore.com> In-Reply-To: Brian Bulkowski "RTCP RR's" (Nov 12, 3:22am) References: <3.0b36.32.19961112032241.007789e8@gw.navio.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: Brian Bulkowski , rem-conf@es.net Subject: Re: RTCP RR's Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii > First, it appears that each client has to keep track of the SSRCs of all > other clients in order to be able to judge the rate at which to send out > RRs, and the time of the last RR they heard from that client. You don't need to keep track of all of them. There are two ways out: 1) Just get a reasonably sized sample, and look at the average sending rate for the sampled group members. 2) Get an estimate of the number of stations in the group, and use it to determine the average rate at which you should send. -- Christian Huitema From rem-conf-request@es.net Tue Nov 12 13:32:24 1996 Received: from INET-05-IMC.itg.microsoft.com (actually mail5.microsoft.com) by osi-east.es.net with ESnet SMTP (PP); Tue, 12 Nov 1996 10:31:43 -0800 Received: by INET-05-IMC.itg.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BBD085.1D4E5040@INET-05-IMC.itg.microsoft.com>; Tue, 12 Nov 1996 10:34:42 -0800 Message-ID: From: Thomas Pfenning To: 'Brian Bulkowski' , "'rem-conf@es.net'" , 'Stephen Casner' Subject: RE: RTCP RR's Date: Tue, 12 Nov 1996 10:31:24 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 81 TEXT No your evaluation looks right on the point. The same problem appears in a plain modem dialup network with large auditoriums. This might be the reason this topic has been added to the agenda for San Jose. Having the clients independently tweak the parameter does not sound feasible. The best location to decide about throttling the RTCP data is on a fast backbone where a listener actually has the bandwidth of receiving all the RTCP packets and updates the real number of users in that group. The low level problem is that of slow distribution of shared state which takes all participants in an RTP channel to send a packet at least once. One way or the other they need hints to converge faster. Another option is aggregation of RTCP packets in some form. Cheers Thomas >-----Original Message----- >From: Brian Bulkowski [SMTP:brianb@navio.com] >Sent: Tuesday, November 12, 1996 3:23 AM >To: rem-conf@es.net; Stephen Casner >Subject: RTCP RR's > >Since someone else asked a bits-and-bytes protocol question here, I'll ask >mine. > >This is about RR's. > >First, it appears that each client has to keep track of the SSRCs of all >other clients in order to be able to judge the rate at which to send out >RRs, and the time of the last RR they heard from that client. This would >mean that the memory requirement would scale linearly with the number of >listeners. In a cable TV system there may easily be 250,000 clients tuned >in, each of which would need about 10 bytes per other receiver, thus >requiring 2.5MB of memory just to keep track of the receiver SSRCs. The >cable TV boxes in these cases rarely have more than 512K of memory, the new >ones as high as 2MB (that's for the OS, the application, fonts, cache and >frame buffer, and no VM), so this is flat-out impossible. > >So how do you decide how to rate out RR packets if you can't keep track of >the SSRCs of all other clients? Pick a really small number; one packet per >hour? > >Second is that cable systems are highly asymetric. You might easily have a >3Mbit/sec downlink, and a shared 9600 baud slotted aloha uplink. Given the >guidelines in RFC 1889, the RTCP RR packets would overwhelm the uplink, and >congest it into the ground in short order. In fact, the algorythms >specified tend towards congestion. As the uplink congests, clients would >decide that there are fewer other clients around, and attempt to send more >packets, thus congesting the link further. > >There are a number of other pathological-to-RTCP networks that have already >been built. I haven't even started with satellite systems. > >Remember further that as a client, you might not be able to detect that you >are on one of these networks. In the case of a low-end PC on a cable modem, >the PC is on 10Mb/sec ethernet, and the cable modem is effectivly an >ethernet<->broadband bridge. On these networks there is no extra software >on the PC side: it thinks it runs regular ethernet, it runs regular >WinSock, CU-CMe, whatever. The cable modem companies can't use the serial >port (too slow for the downlink), and don't want to build PC cards, >especially when ISA ethernet cards are running $30. I think @Home's trials >are using beefier uplinks, and PCs do have VM and hard drives, but the >problems still exist. > >Thus, does every RTP implementation need to have user-setable parameters >for the percentage of the downlink and using different algorythms for RR >packet send rating? Shouldn't this be spec'd? How can we trust the user to >tweak this parameter, since the code can't adjust itself, and the results >of a mistake are disasterous: congestion collapse? > >Or is there something fundamental that I'm missing about RR packets? > >Please enlighten. > >Cheers, >-brianb >brian bulkowski >Technical Project Lead, Navio Communications >brianb@navio.com, brian@bulkowski.org > From rem-conf-request@es.net Tue Nov 12 16:59:52 1996 Received: from mercury.lcs.mit.edu by osi-east.es.net with ESnet SMTP (PP); Tue, 12 Nov 1996 13:59:05 -0800 Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id QAA26288; Tue, 12 Nov 1996 16:56:03 -0500 X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Thomas Pfenning cc: rem-conf@es.net Subject: Re: RTCP RR's In-reply-to: Your message of "Tue, 12 Nov 96 10:31:24 PST." Date: Tue, 12 Nov 96 16:56:03 -0500 Message-ID: <27290.847835763@mercury.lcs.mit.edu> Sender: mjh@mercury.lcs.mit.edu X-Mts: smtp >The low level problem is that of slow distribution of shared >state which takes all participants in an RTP channel to send a packet at >least once. One way or the other they need hints to converge faster. >Another option is aggregation of RTCP packets in some form. Even for sessions in which the participants need (or would like) to know the other participants, there are scaling problems with RTCP as it's specified right now. If you look at the dynamics of the RTCP rate adaption, it does a binary exponential backoff from it's initial timer value of 5 seconds until it converges on the size of the membership when the time elapsed since startup is greater than the converged value for the number of participants. With a session with 1000 participants, and a mean RTCP packet size of 60 bytes in a 64Kbps audio session (3.2Kbps RTCP b/w), we get one RTCP report every ~7 RTCP reports/second, (i.e, take 150 seconds for every receiver to report). A new receiver will report 5 times in this 150 second interval before it has a good picture of the receivership. Now, if many people join all at once (say 100 new people join together as they might if sdr automated tool startup at session startup time for example) then we get a significant burst of extra RTCP traffic above the desired level while these new members converge. Another example where a problem might occur is when we have a large number of members, but the mean membership duration is short. Say mean membership duration is 10 minutes. Then (to a first approximation) each participant in a 1000 person session sends 5 startup reports, plus 3 normal reports instead of the 4 reports it should have sent. Thus RTCP traffic is double the desired rate, even though all participants are trying to do the right thing. For most sessions, neither of these effects are likely to be a big problem, but people should bear them in mind when looking at large RTCP sessions. For *broadcast* RTP sessions (ie, there can only be one sender of the media streams) where the participants do not need to know each other, I suspect randomly jittered unicasting of RTCP reports which are rate-triggered by the sender is probably a useful alternative in those cases where the sender has much more spare incoming bandwidth than the expected receivers. Mark From rem-conf-request@es.net Tue Nov 12 20:25:23 1996 Received: from galaxy (actually galaxy.net.edu.cn) by osi-east.es.net with ESnet SMTP (PP); Tue, 12 Nov 1996 17:24:49 -0800 Received: from synet.edu.cn (saint.synet.edu.cn) by galaxy (5.x/SMI-SVR4) id AA08396; Wed, 13 Nov 1996 09:25:34 +0800 Received: from neu.edu.cn (bengal.neu.edu.cn) by synet.edu.cn (5.x/SMI-SVR4) id AA10573; Wed, 13 Nov 1996 08:24:28 +0800 Received: from ncsc.neu.edu.cn (conger) by neu.edu.cn (4.1/SMI-4.1) id AA02001; Wed, 13 Nov 96 08:22:38 CST Received: by ncsc.neu.edu.cn (5.x/SMI-SVR4) id AA06885; Wed, 13 Nov 1996 09:22:55 +0800 Date: Wed, 13 Nov 1996 09:22:54 +0800 (CST) From: Niu Junyu Subject: Re: 37th IETF SAN JOSE: AVT To: Stephen Casner Cc: rem-conf@es.net In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I am a new user of MBone. Now I have built a Mrouter,I want to connect with others .The mrouter's IP address is 202.118.0.81.Would you like to tell me whom should I connect with? Thank you. Niujy From rem-conf-request@es.net Wed Nov 13 02:10:40 1996 Received: from mail.gmd.de by osi-east.es.net with ESnet SMTP (PP); Tue, 12 Nov 1996 23:09:59 -0800 Received: by mail.gmd.de id AA10593 (5.67b8/IDA-1.5 for rem-conf@es.net); Wed, 13 Nov 1996 08:09:49 +0100 Date: Wed, 13 Nov 1996 08:09:49 +0100 From: Hans Mayer Message-Id: <199611130709.AA10593@mail.gmd.de> To: casner@precept.com, niujy@conger.synet.edu.cn Subject: Re: 37th IETF SAN JOSE: AVT Cc: rem-conf@es.net >I am a new user of MBone. Now I have built a Mrouter,I want to connect >with others .The mrouter's IP address is 202.118.0.81.Would you like to >tell me whom should I connect with? Get in touch with xyong@csnet4.dcs.tsinghua.edu.cn. It doesn't make sense if every university or research institute in China gets it's own MBONE connection to the U.S. You should coordinate loacally and try to set up the infrastructure first and see, if that works. As far as I know the internal capacity of the Chinese research network links is 64 kbit/sec only so a general connection to the MBONE might overload your network. Hans From rem-conf-request@es.net Wed Nov 13 06:42:31 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Wed, 13 Nov 1996 03:41:57 -0800 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 13 Nov 1996 11:37:05 +0000 From: Isidor Kouvelas X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3670 To: Carlos Picoto cc: "MBone@ISI.Edu" , rem-conf@es.net, I.Kouvelas@cs.ucl.ac.uk Subject: Re: VIC on Windows with grabber ? In-reply-to: Your message of "Wed, 13 Nov 1996 10:47:16 +0100." <01BBD150.0AA5FDA0@eagle> Date: Wed, 13 Nov 1996 11:37:01 +0000 Message-ID: <1086.847885021@cs.ucl.ac.uk> Sender: I.Kouvelas@cs.ucl.ac.uk >Where can I find any alpha version of VIC for Windows95/NT >with a video for windows grabber ? You can find a fairly complete port of vic 2.8 with Video For Windows grabber support for NT and 95 at: http://www.cs.ucl.ac.uk/staff/I.Kouvelas/vic The main known problem with this binary is that it will not work with 16 bit PC displays. You have to run your display at 256 colors or 24 bit to display the video. If anyone knows a workaround to this I would be very interested to hear from you. Isidor From rem-conf-request@es.net Wed Nov 13 10:13:43 1996 Received: from FNAL.FNAL.Gov by osi-east.es.net with ESnet SMTP (PP); Wed, 13 Nov 1996 07:13:08 -0800 Received: from gungnir.fnal.gov ("port 33983"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IBSITMZPZA00019Y@FNAL.FNAL.GOV>; Wed, 13 Nov 1996 09:13:03 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA17245; Wed, 13 Nov 1996 09:12:12 -0600 Date: Wed, 13 Nov 1996 09:12:12 -0600 From: Matt Crawford Subject: Re: RTCP RR's In-reply-to: "12 Nov 1996 13:25:10 EST." <"9611121325.ZM10336"@seawind.bellcore.com> Sender: crawdad@gungnir.fnal.gov To: huitema@bellcore.com (Christian Huitema) Cc: Brian Bulkowski , rem-conf@es.net Message-id: <199611131512.JAA17245@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{ > First, it appears that each client has to keep track of the SSRCs of all > > other clients in order to be able to judge the rate at which to send out > > RRs, and the time of the last RR they heard from that client. > > You don't need to keep track of all of them. There are two ways out: > 1) Just get a reasonably sized sample, and look at the average > sending rate for the sampled group members. I'm not an RTP guru, but this looks unstable -- any members that pick a rate too high or too low drag other members in the same direction. Matt From rem-conf-request@es.net Wed Nov 13 12:46:46 1996 Received: from DECOSI.ksc.nasa.gov by osi-east.es.net with ESnet SMTP (PP); Wed, 13 Nov 1996 09:46:08 -0800 Received: from localhost by DECOSI.ksc.nasa.gov; (5.65v3.2/1.1.8.2/23May94-0520PM) id AA08037; Wed, 13 Nov 1996 12:44:50 -0500 Message-Id: <9611131744.AA08037@DECOSI.ksc.nasa.gov> To: rem-conf@es.net Subject: Receiving IP Multicast via Token Ring Date: Wed, 13 Nov 96 12:44:50 -0500 From: rje@DECOSI.ksc.nasa.gov X-Mts: smtp Does anyone have any experience with or know anything about receiving IP multicast on a Token Ring connected machine? From what I have read T.R. does not have multicast capabilities. Also the direct mapping from IP address to ethernet address would probably not work. Have there been any attempts to do it using T.R. broadcast or some other method I am not aware of? Perhaps a router that would listen to all the "joins" on the segment and maintain a table for each individual machine? Any help would be GREATLY appreciated. Thanx. R.J. Edwards From rem-conf-request@es.net Wed Nov 13 13:22:19 1996 Received: from ormail.intel.com by osi-east.es.net with ESnet SMTP (PP); Wed, 13 Nov 1996 10:21:37 -0800 Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.8.2/8.7.3) with ESMTP id KAA08125 for ; Wed, 13 Nov 1996 10:21:09 -0800 (PST) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.8.2/8.7.3) id KAA08812 for rem-conf@es.net; Wed, 13 Nov 1996 10:21:06 -0800 (PST) Original-Received: by ccm.hf.intel.com (ccmgate 3.2 #7) Wed, 13 Nov 96 10:21:04 PST PP-warning: Illegal Received field on preceding line Date: Wed, 13 Nov 96 10:19:00 PST From: John H Wilson Message-ID: To: rem-conf@es.net Subject: Re-keying RTP streams In H.323 (A/V conferencing as defined by the ITU), the media streams are transported by RTP; each stream also having a corresponding RTCP channel. Both the RTP and the RTCP channels are (of course) unreliable. H.323 also has a reliable (TCP) control channel (H.245) which is used to set up the RTP/RTCP channels and to control the conference. This channel remains open for the duration. [In a multipoint conference, each endpoint has a separate H.245 channel to the Conference Controller (the MC), and the RTP/RTP channels are multicast. In general, the H.245 channel cannot be used to communicate amongst endpoints; between transmitter and receivers]. In extending H.323 to provide private communications, the H.245 channel becomes secure (using TLS), and the security parameters for an RTP channel [the RTCP channel is not encrypted] are negotiated on it(them). In particular, the keys for the RTP channel are distributed on the H.245 channel(s) by the MC. All before thr RTP/RTCP sessions are established. The problem arises when the MC needs to distribute fresh keys after some period (or because the old key has been compromised for some reason). There's no problem in distributing the new keys (this is done on the reliable, secure H.245 channel). But how should the Transmitter and Receiver (or multiple receivers, in the multicast case) synchronize on the new key? The H.245 channel cannot be used for this purpose, since it does not (at least in the multipoint case) connect the transmitter to all receivers. We are left with just the RTP and RTCP channels. The RTP headers contain both sequence numbers and timestamps. There are two proposals: 1. There is a bit in all RTCP packets which flips when a new key starts being used on the RTP stream (and remains in the new state until the next key change). The first packet of the new state also contains the sequence number of the RTP stream at which the new key starts to apply. (This packet could be sent several times). A receiver will always see the bit flip but, if it misses the sequence number, it can immediately start using the new key; some number of RTP packets may have been indecipherable before this point. 2. The bit (as described above) would be in the RTP header (probably requiring an extended header). The receivers would change key as soon as they see the bit flip. I am particularly interested in solution 2; all I need is one bit in the standard RTP header. Can any RTP expert suggest a way of discovering a usable bit. (Maybe from the combination of M and PT?) I am also interested in hearing whether the AVT people considered the problem (and, if so, how they proposed to solve it). john_h_wilson@ccm.jf.intel.com From rem-conf-request@es.net Wed Nov 13 13:22:52 1996 Received: from msri.msri.org (actually msri.org) by osi-east.es.net with ESnet SMTP (PP); Wed, 13 Nov 1996 10:21:53 -0800 Received: (from smap@localhost) by msri.msri.org (8.8.2/8.7.2) id KAA20585 for ; Wed, 13 Nov 1996 10:21:56 -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 sma020572; Wed Nov 13 10:21:09 1996 Received: by hille.msri.org (8.7/MSRI) id KAA08249; Wed, 13 Nov 1996 10:30:38 -0800 (PST) Date: Wed, 13 Nov 1996 10:30:38 -0800 (PST) Message-Id: <199611131830.KAA08249@hille.msri.org> From: joe Reply-to: joe@msri.org Subject: George Andrews, "The Death of Proof" MBone Broadcast Announcement ---------------------------- Title: George Andrews, "The Death of Proof" Date: Nov 18, 1996 Time: 16:15 PST8PDT 1 hours Contact: joe@msri.org URL: http://www.msri.org/lecturenotes/96/andrews/1/ Description: On Monday, November 18 at 4:15PM PST, and again on Tuesday, November 19 at 1:15PM PST, MSRI will be presenting an MBone rebroadcast of George Andrews's lecture "The Death of Proof", (recorded October 14, 1996). Andrews's abstract follows:

Recently John Horgan in the Scientific American and Doron Zeilberger in the A.M.S. Notices provided lengthy articles suggesting that proof as we know it is on the skids. The object of this talk will be to examine the mathematical evidence for these assertions. We hope to show that proof still has some life left in it. We shall especially examine the role of computer algebra system in this controversy. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Wed Nov 13 15:35:40 1996 Received: from mercury.lcs.mit.edu by osi-east.es.net with ESnet SMTP (PP); Wed, 13 Nov 1996 12:34:54 -0800 Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id PAA29521; Wed, 13 Nov 1996 15:30:15 -0500 X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol 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: Re-keying RTP streams In-reply-to: Your message of "Wed, 13 Nov 96 10:19:00 PST." Date: Wed, 13 Nov 96 15:30:15 -0500 Message-ID: <28898.847917015@mercury.lcs.mit.edu> Sender: mjh@mercury.lcs.mit.edu X-Mts: smtp >The problem arises when the MC needs to distribute fresh keys after some >period (or because the old key has been compromised for some reason). > >There's no problem in distributing the new keys (this is done on the >reliable, secure H.245 channel). But how should the Transmitter and >Receiver (or multiple receivers, in the multicast case) synchronize on >the new key? ... >We are left with just the RTP and RTCP channels. You don't need an explicit signal to do this - simply drive it off the data. What you can do is distribute the new keys, and then when you're sure everyone's got them, simply switch to using the new RTP key. The RTP data-stream then fails the decoder's sanity checks, and you try the next key. If this succeeds in decoding the stream properly, then you also switch your own outgoing data stream to use the new key. You keep a table of active sources, and keep track of which ones have switched independently. Note, you need the sanity checks in there anyway to cope with malitious users - tying it to trying the enxt key in a sequence is then pretty trivial. You may need a few packets to perform an initial sanity check on a new SSRC (there's not much redundancy in RTP) but when changing keys you should only need a single packet - if it contains a valid existing SSRC, appropriate PT, and otherwise seems valid, you can probably safely assume it is. I think it was Van that first suggested data-driving the key transfer in this way. Mark From rem-conf-request@es.net Wed Nov 13 15:54:55 1996 Received: from hubbub.cisco.com by osi-west.es.net with ESnet SMTP (PP); Wed, 13 Nov 1996 12:54:21 -0800 Received: from oranlt.cisco.com (oran-toshiba.cisco.com [171.69.210.2]) by hubbub.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id MAA15771; Wed, 13 Nov 1996 12:50:32 -0800 (PST) Message-Id: <3.0b36.32.19961113155030.0071cd74@pointer.cisco.com> X-Sender: oran@pointer.cisco.com X-Mailer: Windows Eudora Pro Version 3.0b36 (32) Date: Wed, 13 Nov 1996 15:50:33 -0500 To: John H Wilson , rem-conf@es.net From: David Oran Subject: Re: Re-keying RTP streams Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In all of your solutions you can miss one packet and then be lost. Have you considered binding the key to the SSRC (so the SSRC sort of works like a keyid), distributing this binding with H.245 (or possibly RTCP as long as the new media stream key is send encrypted under some protected session key). Then, the sender switches SSRCs when he switches keys. This doesn't solve the crypto-synch problem on the media stream, but I assume that is solved in another way since you can always lose arbitrary RTP packets at any point. Dave Oran. At 10:19 AM 11/13/96 PST, John H Wilson wrote: > >In H.323 (A/V conferencing as defined by the ITU), the media streams are >transported by RTP; each stream also having a corresponding RTCP >channel. Both the RTP and the RTCP channels are (of course) unreliable. > >H.323 also has a reliable (TCP) control channel (H.245) which is used to >set up the RTP/RTCP channels and to control the conference. This channel >remains open for the duration. [In a multipoint conference, each >endpoint has a separate H.245 channel to the Conference Controller (the >MC), and the RTP/RTP channels are multicast. In general, the H.245 >channel >cannot be used to communicate amongst endpoints; between transmitter and >receivers]. > >In extending H.323 to provide private communications, the H.245 channel >becomes secure (using TLS), and the security parameters for an RTP >channel [the RTCP channel is not encrypted] are negotiated on it(them). >In particular, the keys for the RTP channel are distributed on the H.245 >channel(s) by the MC. All before thr RTP/RTCP sessions are established. > >The problem arises when the MC needs to distribute fresh keys after some >period (or because the old key has been compromised for some reason). > >There's no problem in distributing the new keys (this is done on the >reliable, secure H.245 channel). But how should the Transmitter and >Receiver (or multiple receivers, in the multicast case) synchronize on >the new key? > >The H.245 channel cannot be used for this purpose, since it does not >(at least in the multipoint case) connect the transmitter to all >receivers. > >We are left with just the RTP and RTCP channels. > >The RTP headers contain both sequence numbers and timestamps. > >There are two proposals: > >1. There is a bit in all RTCP packets which flips when a new key starts > being used on the RTP stream (and remains in the new state until the > next key change). The first packet of the new state also contains the > > sequence number of the RTP stream at which the new key starts to > apply. (This packet could be sent several times). A receiver will > always see the bit flip but, if it misses the sequence number, it can > immediately start using the new key; some number of RTP packets may > have been indecipherable before this point. > >2. The bit (as described above) would be in the RTP header (probably > requiring an extended header). The receivers would change key as soon > as they see the bit flip. > >I am particularly interested in solution 2; all I need is one bit in the >standard RTP header. Can any RTP expert suggest a way of discovering a >usable bit. (Maybe from the combination of M and PT?) > >I am also interested in hearing whether the AVT people considered the >problem (and, if so, how they proposed to solve it). > >john_h_wilson@ccm.jf.intel.com > > ----------------- David R. Oran Cisco Systems Direct: 408-527-0567 7 Ladyslipper Lane Home Office: 508-264-2048, Home: 508-263-2705 Acton, MA 01720 EMail: oran@cisco.com From rem-conf-request@es.net Thu Nov 14 03:36:00 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Thu, 14 Nov 1996 00:35:03 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA17587; Thu, 14 Nov 1996 00:28:15 -0800 Date: Thu, 14 Nov 1996 00:28:14 -0800 (PST) From: Stephen Casner To: Mark Handley Cc: John H Wilson , rem-conf@es.net Subject: Re: Re-keying RTP streams In-Reply-To: <28898.847917015@mercury.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 13 Nov 1996, Mark Handley wrote: > You don't need an explicit signal to do this - simply drive it off the > data. Yes. This is the scheme suggested in section 9.1 of RFC 1889, though Mark has filled in a number of details that the spec does not go into. If, as suggested in 9.1, the entire RTP packet is encrypted, then there is no value in carving out a bit from the RTP header, or specifying a sequence number for the switchover, or in changing to a new SSRC. None of those changes would be visible before decryption. -- Steve From rem-conf-request@es.net Thu Nov 14 03:40:35 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Thu, 14 Nov 1996 00:39:57 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA17592; Thu, 14 Nov 1996 00:37:59 -0800 Date: Thu, 14 Nov 1996 00:37:58 -0800 (PST) From: Stephen Casner To: Matt Crawford Cc: Christian Huitema , Brian Bulkowski , rem-conf@es.net Subject: Re: RTCP RR's In-Reply-To: <199611131512.JAA17245@gungnir.fnal.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > You don't need to keep track of all of them. There are two ways out: > > 1) Just get a reasonably sized sample, and look at the average > > sending rate for the sampled group members. > > I'm not an RTP guru, but this looks unstable -- any members that pick > a rate too high or too low drag other members in the same direction. Perhaps instability can be avoided with a sufficiently large sample and through the use of mechanisms such as median filters and the like, similar to what Dr. Mills does to separate the truechimers from the falsetickers in NTP. -- Steve From rem-conf-request@es.net Thu Nov 14 05:32:43 1996 Received: from acacia.sucs.soton.ac.uk by osi-east.es.net with ESnet SMTP (PP); Thu, 14 Nov 1996 02:31:54 -0800 Received: from apollo.sucs.soton.ac.uk (apollo.sucs.soton.ac.uk [152.78.128.224]) by acacia.sucs.soton.ac.uk (8.8.2/server) with SMTP id KAA02052; Thu, 14 Nov 1996 10:29:50 GMT Date: Thu, 14 Nov 1996 10:28:14 GMT From: David Holter Subject: Re: VIC on Windows with grabber ? To: Isidor Kouvelas cc: Carlos Picoto , "MBone@ISI.Edu" , rem-conf@es.net, I.Kouvelas@cs.ucl.ac.uk Message-ID: Priority: Normal MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Wed, 13 Nov 1996 11:37:01 +0000 Isidor Kouvelas wrote: > From: Isidor Kouvelas > Date: Wed, 13 Nov 1996 11:37:01 +0000 > Subject: Re: VIC on Windows with grabber ? > To: Carlos Picoto > Cc: "MBone@ISI.Edu" , rem-conf@es.net, > I.Kouvelas@cs.ucl.ac.uk > > >Where can I find any alpha version of VIC for Windows95/NT > >with a video for windows grabber ? > > You can find a fairly complete port of vic 2.8 with Video For Windows > grabber support for NT and 95 at: > > http://www.cs.ucl.ac.uk/staff/I.Kouvelas/vic > > The main known problem with this binary is that it will not work with 16 bit > PC displays. You have to run your display at 256 colors or 24 bit to display > the video. If anyone knows a workaround to this I would be very interested > to hear from you. > > Isidor Which Video capture card does this work with? Regards David From rem-conf-request@es.net Thu Nov 14 05:59:40 1996 Received: from cancer.ucs.ed.ac.uk by osi-east.es.net with ESnet SMTP (PP); Thu, 14 Nov 1996 02:59:00 -0800 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with SMTP id KAA15798; Thu, 14 Nov 1996 10:56:08 GMT Date: Thu, 14 Nov 1996 10:56:06 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: David Holter cc: Isidor Kouvelas , Carlos Picoto , "MBone@ISI.Edu" , rem-conf@es.net Subject: Re: VIC on Windows with grabber ? In-Reply-To: Message-ID: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-URL: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 14 Nov 1996, David Holter wrote: > > >Where can I find any alpha version of VIC for > Windows95/NT > > >with a video for windows grabber ? > > > > You can find a fairly complete port of vic 2.8 with Video > For Windows > > grabber support for NT and 95 at: > > > > http://www.cs.ucl.ac.uk/staff/I.Kouvelas/vic > > > > The main known problem with this binary is that it will > not work with 16 bit > > PC displays. You have to run your display at 256 colors or > 24 bit to display > > the video. If anyone knows a workaround to this I would be > very interested > > to hear from you. > > > > Isidor > > > Which Video capture card does this work with? That web document lists a number of cards which have been tested. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From rem-conf-request@es.net Thu Nov 14 07:44:50 1996 Received: from master.di.fc.ul.pt by osi-east.es.net with ESnet SMTP (PP); Thu, 14 Nov 1996 04:44:04 -0800 Received: from eagle (eagle.di.fc.ul.pt [192.67.76.20]) by master.di.fc.ul.pt (8.6.11/8.6.12) with SMTP id MAA10054; Thu, 14 Nov 1996 12:43:13 GMT Received: by eagle with Microsoft Mail id <01BBD228.C4055830@eagle>; Thu, 14 Nov 1996 12:38:41 +0100 Message-ID: <01BBD228.C4055830@eagle> From: Carlos Picoto To: David Holter , "'Graeme.Wood@ucs.ed.ac.uk'" Cc: Isidor Kouvelas , Carlos Picoto , "MBone@ISI.Edu" , "rem-conf@es.net" Subject: RE: VIC on Windows with grabber ? Date: Thu, 14 Nov 1996 12:38:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Isidor and others, I'm using the comercial version of NT (build 1381) with Quickcam B&W. Results: When I try to transmit, it crashes the machine while trying to access the tape device.... Can I use any command line switches to bypass this problem I know the driver is bad, but with nvat I have "minor" problems only. If you have a debug version I can run it on a checked build environment. Thanks for any help ./Carlos Picoto ---------- From: Graeme Wood Sent: Thursday, November 14, 1996 11:56 AM To: David Holter Cc: Isidor Kouvelas; Carlos Picoto; MBone@ISI.Edu; rem-conf@es.net Subject: Re: VIC on Windows with grabber ? On Thu, 14 Nov 1996, David Holter wrote: > > >Where can I find any alpha version of VIC for > Windows95/NT > > >with a video for windows grabber ? > > > > You can find a fairly complete port of vic 2.8 with Video > For Windows > > grabber support for NT and 95 at: > > > > http://www.cs.ucl.ac.uk/staff/I.Kouvelas/vic > > > > The main known problem with this binary is that it will > not work with 16 bit > > PC displays. You have to run your display at 256 colors or > 24 bit to display > > the video. If anyone knows a workaround to this I would be > very interested > > to hear from you. > > > > Isidor > > > Which Video capture card does this work with? That web document lists a number of cards which have been tested. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From rem-conf-request@es.net Thu Nov 14 11:06:44 1996 Received: from dxmint.cern.ch by osi-east.es.net with ESnet SMTP (PP); Thu, 14 Nov 1996 08:06:01 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id RAA01605; Thu, 14 Nov 1996 17:05:05 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA09769; Thu, 14 Nov 1996 17:05:05 +0100 Message-Id: <9611141605.AA09769@dxcoms.cern.ch> Subject: MBONE Announcement for CERN LEPC To: rem-conf@es.net, hepnet-l@slacvm.slac.stanford.edu, hrc@frcpn11.in2p3.fr, htasc@listbox.cern.ch, net-teleconferencing@listbox.cern.ch Date: Thu, 14 Nov 1996 17:05:05 +0100 (MET) From: Martin Fluckiger - CERN/CN/CS Cc: fle@dxcoms.cern.ch (Martin Fluckiger) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit CERN is pleased to announce the MBONE broadcast of the LEP Committee Open Session -------------------------- on Tuesday 19 November 1996 at 09:00 (UTC+2) from CERN Auditorium Provisional Agenda: ------------------- >>> Times are UTC+2 <<< Reports on the LEP machine: 09:00 - 09:30 LEP2 status (Mike Lamont) 09:30 - 10:00 LEP2 energy calibration (Mike Hildreth) Reports on the LEP experiments: 10:00 - 10:30 OPAL (Austin Ball) 10:30 - 11:00 Coffee break 11:00 - 11:30 ALEPH (Francesco Ragusa) 11:30 - 12:00 DELPHI (Johannes Timmermans) 12:00 - 12:30 L3 (David Stickland) 12:30 - 13:00 Report on the Electroweak Working Group (Bob Clare) The broadcast is announced via sdr as "CERN LEPC". vat and vic applications will be used with a ttl of 127. In case of questions or problems please contact . This message is sent to distribution lists, sorry if you receive multiple copies of it. Best regards, -------------------------------------------------------------------- Martin Fluckiger & Christian Isnard CERN - CN/CS/EN multicast@noc.cern.ch European Laboratory for Particle Physics Computers and Networks division CH-1211 Geneva 23 - Switzerland From rem-conf-request@es.net Thu Nov 14 11:55:39 1996 Received: from ormail.intel.com by osi-east.es.net with ESnet SMTP (PP); Thu, 14 Nov 1996 08:54:42 -0800 Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.8.2/8.7.3) with ESMTP id IAA06559; Thu, 14 Nov 1996 08:54:16 -0800 (PST) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.8.2/8.7.3) id IAA28962; Thu, 14 Nov 1996 08:54:14 -0800 (PST) Original-Received: by ccm.jf.intel.com (ccmgate 3.2 #6) Thu, 14 Nov 96 08:54:14 PST PP-warning: Illegal Received field on preceding line Date: Thu, 14 Nov 96 08:51:00 PST From: John H Wilson Message-ID: To: jtoga , prl@ibeam.jf.intel.com, casner@precept.com, mjh@isi.edu cc: rem-conf@es.net Subject: Re[2]: Re-keying RTP streams Text item: On Thur, 14 Nov 1996, Steve Casner wrote: >On Wed, 13 Nov 1996, Mark Handley wrote: > >> You don't need an explicit signal to do this - simply drive it off the >> data. > >Yes. This is the scheme suggested in section 9.1 of RFC 1889, though >Mark has filled in a number of details that the spec does not go into. > >If, as suggested in 9.1, the entire RTP packet is encrypted, then >there is no value in carving out a bit from the RTP header, or >specifying a sequence number for the switchover, or in changing to a >new SSRC. None of those changes would be visible before decryption. > > -- Steve Agreed. I think Mark's scheme only works if the complete header is encrypted. However, we are considering NOT encrypting the RTP header because: a) We think it may be worth encrypting only part of the stream (particularly for video streams, you don't have to encrypt much to make it unintelligible), and this would have to be done above the RTP layer. b) for slow links (particularly dial-up links), we would like to be able to compress the RTP header. Therefore, consider the following scheme: For encrypted streams, two dynamic Payload Types are assigned (an initial one, and another). [Since the stream is encrypted, a standard Payload Type is not very useful anyway]. When the key for the stream is changed, the key and the other Payload Type can be communicated using some other secure channel (e.g., the H.245 channels.) When the transmitter can be sure that the receiver(s) have the new key, the transmitter uses it, together with the new Payload Type (which is used until the key changes again; at which point the stream reverts to the original Payload Type). In fact, since the Payload Type is just being used as state for a key change, the same two (canonical) Payload Types could be used for all encrypted RTP streams. John 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-Type: TEXT/PLAIN; charset=US-ASCII Mime-Version: 1.0 Message-Id: In-Reply-To: <28898.847917015@mercury.lcs.mit.edu> Subject: Re: Re-keying RTP streams Cc: John H Wilson , rem-conf@es.net To: Mark Handley From: Stephen Casner Date: Thu, 14 Nov 1996 00:28:14 -0800 (PST) Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA17587; Thu, 14 Nov 1996 00:28:15 -0800 Received: from precept.com (hydra.precept.com [204.162.119.8]) by mailbag.jf.int el.com (8.8.2/8.7.3) with SMTP id AAA12261 for ; Thu, 14 Nov 1996 00:37:30 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id AAA11145 for ; Thu, 14 Nov 1996 00:34:56 -0800 (PST) Return-Path: casner@precept.com From rem-conf-request@es.net Thu Nov 14 14:38:32 1996 Received: from bmrc.Berkeley.EDU by osi-east.es.net with ESnet SMTP (PP); Thu, 14 Nov 1996 11:37:27 -0800 Received: from nobozo.CS.Berkeley.EDU (nobozo.CS.Berkeley.EDU [128.32.34.58]) by bmrc.Berkeley.EDU (8.8.2/8.6.9) with SMTP id LAA21670 for <298-list@bmrc.Berkeley.EDU>; Thu, 14 Nov 1996 11:27:12 -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 LAA24147 for <298-list@bmrc>; Thu, 14 Nov 1996 11:27:13 -0800 Date: Thu, 14 Nov 1996 11:27:13 -0800 Message-Id: <199611141927.LAA24147@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 From: Jerrlyn Iwata Subject: Berkeley Multimedia & Graphics Seminar Berkeley Multimedia and Graphics Seminar (Wednesday November 20, 1996 12:30-2:00 PDT 405 Soda Hall) "The Visual Instruction Set" Robert Yung Sun Microsystems Laboratories UltraSPARC-I (Spitfire) is the first microprocessor from SUN that implements the Visual Instruction Set Extension to the 64-bit SPARC version 9 instruction set architecture. VIS comprises of instructions that accelerates 2D/3D synthetic graphics, image processing and multi-media applications. In this talk, the VIS data types and instruction set will be presented. I will also give an overview of the issues and difficulties involved in obtaining high performance in graphics and multi-media applications. _______________________________________________________________________________ This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40 PDT (GMT - 8 hrs). See sd 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 Nov 15 03:44:54 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Fri, 15 Nov 1996 00:44:13 -0800 Received: from port4.precept.com by precept.com (5.x/SMI-4.1) id AA20070; Fri, 15 Nov 1996 00:44:04 -0800 Date: Fri, 15 Nov 1996 01:54:07 -0800 (PST) From: Stephen Casner To: rem-conf@es.net Subject: Re: RTCP RR's In-Reply-To: <27290.847835763@mercury.lcs.mit.edu> Message-Id: X-X-Sender: casner@little-bear.precept.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A number of questions have been raised on this list regarding the use of RTCP in certain scenarios. I believe this is a topic we need to discuss further both on this list and at the upcoming IETF as part of preparing the RTP spec for advancement to Draft Standard status. The spec currently mandates the use of RTCP in "the IP multicast environment" because of its value in diagnosing faults in the multicast distribution mechanism. What we found with experiments on the MBone was that we needed to make use of the data flow itself in order to diagnose distribution problems. Network managers are understandably concerned about the difficulty of managing multicast data distribution, so as protocol designers we wanted to provide a solution. We wanted to avoid having applications developed and deployed with the result that when customers complained to their service providers about the quality of reception, the service providers would have no means to figure out the problem. For the experimental MBone, this makes a lot of sense. Users are typically pretty network-aware and are interested in diagnosing the problems that affect their reception. They want to know if the problems they see are local or global so they know whether to pursue local solutions. Van Jacobson has reported that even management types within LBL have used this feedback. It also seemed to us that anyone who was transmitting a signal would care how well that signal was being received. After all, this is one of the functions of a transport protocol. An obvious answer is to have receivers report directly back to the sender, but as a couple of serious router meltdowns demonstrated in the early days of the MBone, sending feedback without rate control can cause a severe implosion problem. The solution of multicasting the feedback so that all parties can scale the rate and take advantage of the information at the same time is appealing because it applies over a wide range of scenarios and session sizes. For conferencing applications, the RTCP rate adjustment scales to a few thousand participants. It remains "safe", but it becomes less effective for tracking conference participation because of the time between reports. On the other hand, as the size of the session grows, particpants probably don't care as much to know who all the other participants are. The increased interval between reports (17 minutes was given as an example in an earlier message) does not make RTCP useless. The "loss fraction" field is there to allow single reports to be used in isolation. Although reports from a particular receiver come infrequently, the aggregate rate of reports from all receivers remains roughly constant as the session size scales, so there are plenty of loss-rate data points. -- Steve From rem-conf-request@es.net Fri Nov 15 04:08:04 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Fri, 15 Nov 1996 01:07:27 -0800 Received: from port4.precept.com by precept.com (5.x/SMI-4.1) id AA20080; Fri, 15 Nov 1996 01:00:27 -0800 Date: Fri, 15 Nov 1996 02:10:30 -0800 (PST) From: Stephen Casner To: John H Wilson Cc: rem-conf@es.net Subject: Re: Re[2]: Re-keying RTP streams In-Reply-To: Message-Id: X-X-Sender: casner@little-bear.precept.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Agreed. I think Mark's scheme only works if the complete header is encrypted. > > However, we are considering NOT encrypting the RTP header because: > > a) We think it may be worth encrypting only part of the stream (particularly > for video streams, you don't have to encrypt much to make it > unintelligible), and this would have to be done above the RTP layer. > b) for slow links (particularly dial-up links), we would like to be able to > compress the RTP header. As I was reading your message, this was the bottom of the first screen on the 24-line display of the brain-dead telnet program, and I was mentally formulating the reply to your messge: the scenario you describe is the alternative method covered in the last paragraph of section 9.1 of the RTP spec, in which the payload type field is used to identify encrypted encodings. > Therefore, consider the following scheme: > > For encrypted streams, two dynamic Payload Types are assigned (an initial one, > and another). [Since the stream is encrypted, a standard Payload Type is not > very useful anyway]. Bingo! > In fact, since the Payload Type is just being used as state for a key change, > the same two (canonical) Payload Types could be used for all encrypted RTP > streams. Well, you may want to use more than two payload types if the key switching scheme is more complicated. Also, if multiple encodings might be used, then you might need more dynamic payload types to indicate encoding switches in addition to key switches. -- Steve From rem-conf-request@es.net Fri Nov 15 06:18:48 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Fri, 15 Nov 1996 03:18:01 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 15 Nov 1996 11:17:14 +0000 to: rem-conf@es.net Subject: Re: RTCP RR's In-reply-to: Your message of "Fri, 15 Nov 1996 01:54:07 PST." Date: Fri, 15 Nov 1996 11:17:00 +0000 Message-ID: <1666.848056620@cs.ucl.ac.uk> From: Jon Crowcroft steve casner wrote: >The increased interval between reports (17 minutes was given as an >example in an earlier message) does not make RTCP useless. The "loss >fraction" field is there to allow single reports to be used in >isolation. Although reports from a particular receiver come >infrequently, the aggregate rate of reports from all receivers >remains roughly constant as the session size scales, so there are >plenty of loss-rate data points. just to emphasize this further- as the net grows, the number of hops doesn't grow linearly, but more like log or less...so the number of links in a multicast grows maybe as log log of number of receivers...the constant overal statistics reporting sample rate the therefore INCREASES accuracy even though the report rate from each individual receiver decrease, since the larger the group, the better it "samples" the multicast tree(s)..... for dense trees this is greatr - for sparse large receiver sets it might not be so good, but if/when we deploy sparse mode PIM or you use CBT, this will get better still Note also - a lot of people are working on rate adavptive media streams, and on layered schemes the reports allow you to a) build a rate adaptor that might look a bit like a TCP (thus co-exist with "well behaved" van jacobson congestion avodiance tcp sources, and even approximate to fair shares of bottleneck links....) b) build sources that can dynamically CHOOSE the number of layers and rate of each layer depending on received heterogeneity of receiver reports.... given the number of different link speeds in the access nets to the Internet, you only need statistical sampling a la rtp rr's to do this very effectively... cheers jon From rem-conf-request@es.net Fri Nov 15 11:20:58 1996 Received: from dirty.bell-labs.com (actually dirty.research.bell-labs.com) by osi-east.es.net with ESnet SMTP (PP); Fri, 15 Nov 1996 08:20:21 -0800 Received: from research.bell-labs.com by dirty; Fri Nov 15 11:20:48 EST 1996 Received: from boole.dnrc.bell-labs.com by research; Fri Nov 15 11:17:46 EST 1996 Received: from boole (localhost [127.0.0.1]) by boole.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id LAA00210; Fri, 15 Nov 1996 11:18:14 -0500 (EST) Sender: hgs@dnrc.bell-labs.com Message-ID: <328C97C5.794BDF32@cs.columbia.edu> Date: Fri, 15 Nov 1996 11:18:13 -0500 From: "Prof. Henning Schulzrinne" Organization: Bell Laboratories X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3 sun4m) MIME-Version: 1.0 To: Christiaan Balke CC: rem-conf@es.net Subject: Re: Mbone toolset integration, SDR References: <3289F717.5D5E@fys.ruu.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Christiaan Balke wrote: > > Hallo, > > At the Utrecht University, computational physics group, we are working > in the REMOT project to build a virtual control room for > plasma physici. (see http://www.fys.ruu.nl/~wwwfi/remot/REMOT_main.html) > We are using and testing a few Mbone tools and have a > question to this list. This is really a rem-conf question (I think...), so I'm redirecting follow-up. For a working example of something similar to what you describe see the Mint system at http://www.fokus.gmd.de/step/mint It uses a single session controller for all media types, with fully "remote controllable" media agents. We have done this both for a new set of media agents as well as backfitting a subset of this into vic. > > The question is about the "Conference Bus" as described in the > article: > "vic: A flexible framework for packet video" :1995 > > In section 4.6 it is said that the LBL group is working on an > integrated > interface for a set of mbone tools. This idea is very usefull in our > project. At the moment a conference session uses a whole screen full > with windows from standalone applications and we are thinking of > writing a common user interface for a (more or less) complete set of > tools (audio, video, whiteboard). It would help us a great deal if we > could use what is already available. > Does anybody know some more of this project and how it is working? > > We are also looking for the source code of SDR. Any Pointers? > Thanks > > Hartelijke groeten > > Christiaan > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > A.C. Balke | E-mail : a.c.balke@fys.ruu.nl > =-=-=-=-=--=-=-=- Tel : +31-030-2534504 > FAX : +31-302537555 > WWW : http://www.fys.ruu.nl/~balke/chris_home_pers.html > Department of Physics & Astronomy, Utrecht University > Post box 80.000, 3508 TA Utrecht, The Netherlands. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ><> =- From rem-conf-request@es.net Fri Nov 15 11:37:50 1996 Received: from uranus.vdo.co.il by osi-east.es.net with ESnet SMTP (PP); Fri, 15 Nov 1996 08:37:12 -0800 Received: from stas.vdo.co.il ([199.203.118.2]) by uranus.vdo.co.il (8.6.12/8.6.12) with SMTP id SAA06507 for ; Fri, 15 Nov 1996 18:36:00 +0200 Received: by stas.vdo.co.il with Microsoft Mail id <01BBD324.0D7E8760@stas.vdo.co.il>; Fri, 15 Nov 1996 18:37:28 +-200 Message-ID: <01BBD324.0D7E8760@stas.vdo.co.il> From: Stas Khirman To: "'rem-conf@es.net'" Subject: G.711,G.723.1 and H.263 payloads need Date: Fri, 15 Nov 1996 18:37:26 +-200 Encoding: 8 TEXT Hello Everyone, I am looking for RTP payload formats for G.711,G.723.1 and H.263. If someone could point me to appropriate sources I'd greatly appreciate it. Thanks for your help. Stas Khirman. From rem-conf-request@es.net Fri Nov 15 18:32:06 1996 Received: from gw.navio.com by osi-east.es.net with ESnet SMTP (PP); Fri, 15 Nov 1996 15:31:18 -0800 Received: (from proxy@localhost) by gw.navio.com (8.6.12/8.6.9) id PAA06538; Fri, 15 Nov 1996 15:31:11 -0800 Received: from lulu.navio.com(204.182.38.230) by tvsoft.com via smap (V1.3) id sma006527; Fri Nov 15 15:30:56 1996 Message-Id: <3.0b36.32.19961115152951.006efd9c@gw.navio.com> X-Sender: brianb@gw.navio.com X-Mailer: Windows Eudora Pro Version 3.0b36 (32) Date: Fri, 15 Nov 1996 15:29:52 -0800 To: Stephen Casner From: Brian Bulkowski Subject: Re: RTCP RR's Cc: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" RTP-interested people: I agree with Stephen's words. I think that the case of "industrial strength" RTP/RTCP applications is somewhat different from what has gone before, and it is part of RTP's flexability to change its behaviour in the face of different application usage. In the cases I'm considering, it is unreasonable for the sender application to change its behaviour in the face of receiving a few ugly looking RTCP packets, unless it gets uniformly ugly packets. In most cases, the congestion point won't be the closest link, and the congestion reason will be hardware related. In a hugely-scaled system (1,000,000 nodes) it is unlikely that all hardware in the cable plant will be working properly. If we expect the sender to scale back to the problems on the least functional link, we will likely have a never-functioning system. This is a two edged sword. If we expect there to be frequent hardware problems that cause congestion problems, it becomes even more important to have sophisticated network management systems to be able to isolate the problem and cause it to be fixed. One solution in this space would be to have RTP mixers scattered around that would be able to segement the RTP session into manageable segments, and have that mixer be able to adjust quickly to a smaller (say, 2000 home) set by scaling back the video. However, this solution is very unattractive. The benefit of using Multicast IP is that you don't have to put any other software in the router/distribution network. If we require RTP mixers as well, we have to leverage Cisco or another company to provide and propigate those bits throughout parts of the network. M-IP still creates value by keeping track of the routing problems, and allowing RTP sub-sessions to cross multiple routers. It wouldn't be a terrible solution, and would be in line with the RTP philosophy. But unattractive. Part of the scalebility problem is keeping track of the network management in order to become a congestion-avoidant protocol. I'm not sure we can abandon RTCP without a different network management solution in mind. RSVP springs to mind, but, of course, it only solves a subset of the problem since it reserves resources in routers, not wires. I think this is a great challange facing RTP, not a fatal flaw. I look forward to further discussion on the topic. -brianb brianb@navio.com At 01:54 AM 11/15/96 -0800, you wrote: >A number of questions have been raised on this list regarding the use >of RTCP in certain scenarios. I believe this is a topic we need to >discuss further both on this list and at the upcoming IETF as part of >preparing the RTP spec for advancement to Draft Standard status. > >The spec currently mandates the use of RTCP in "the IP multicast >environment" because of its value in diagnosing faults in the >multicast distribution mechanism. What we found with experiments on >the MBone was that we needed to make use of the data flow itself in >order to diagnose distribution problems. Network managers are >understandably concerned about the difficulty of managing multicast >data distribution, so as protocol designers we wanted to provide a >solution. We wanted to avoid having applications developed and >deployed with the result that when customers complained to their >service providers about the quality of reception, the service >providers would have no means to figure out the problem. > >For the experimental MBone, this makes a lot of sense. Users are >typically pretty network-aware and are interested in diagnosing the >problems that affect their reception. They want to know if the >problems they see are local or global so they know whether to pursue >local solutions. Van Jacobson has reported that even management >types within LBL have used this feedback. > >It also seemed to us that anyone who was transmitting a signal would >care how well that signal was being received. After all, this is one >of the functions of a transport protocol. An obvious answer is to >have receivers report directly back to the sender, but as a couple of >serious router meltdowns demonstrated in the early days of the MBone, >sending feedback without rate control can cause a severe implosion >problem. The solution of multicasting the feedback so that all >parties can scale the rate and take advantage of the information at >the same time is appealing because it applies over a wide range of >scenarios and session sizes. > >For conferencing applications, the RTCP rate adjustment scales to a >few thousand participants. It remains "safe", but it becomes less >effective for tracking conference participation because of the time >between reports. On the other hand, as the size of the session >grows, particpants probably don't care as much to know who all the >other participants are. > >The increased interval between reports (17 minutes was given as an >example in an earlier message) does not make RTCP useless. The "loss >fraction" field is there to allow single reports to be used in >isolation. Although reports from a particular receiver come >infrequently, the aggregate rate of reports from all receivers >remains roughly constant as the session size scales, so there are >plenty of loss-rate data points. > > > -- Steve > > From rem-conf-request@es.net Fri Nov 15 19:05:28 1996 Received: from gw.navio.com by osi-east.es.net with ESnet SMTP (PP); Fri, 15 Nov 1996 16:04:56 -0800 Received: (from proxy@localhost) by gw.navio.com (8.6.12/8.6.9) id QAA07330; Fri, 15 Nov 1996 16:04:54 -0800 Received: from lulu.navio.com(204.182.38.230) by tvsoft.com via smap (V1.3) id sma007317; Fri Nov 15 16:04:23 1996 Message-Id: <3.0b36.32.19961115160319.006f9e50@gw.navio.com> X-Sender: brianb@gw.navio.com X-Mailer: Windows Eudora Pro Version 3.0b36 (32) Date: Fri, 15 Nov 1996 16:03:19 -0800 To: Stephen Casner From: Brian Bulkowski Subject: Re: RTCP RR's Cc: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" RTP-interested people: I agree with Stephen's words. I think that the case of "industrial strength" RTP/RTCP applications is somewhat different from what has gone before, and it is part of RTP's flexability to change its behaviour in the face of different application usage. In the cases I'm considering, it is unreasonable for the sender application to change its behaviour in the face of receiving a few ugly looking RTCP packets, unless it gets uniformly ugly packets. In most cases, the congestion point won't be the closest link, and the congestion reason will be hardware related. In a hugely-scaled system (1,000,000 nodes) it is unlikely that all hardware in the cable plant will be working properly. If we expect the sender to scale back to the problems on the least functional link, we will likely have a never-functioning system. This is a two edged sword. If we expect there to be frequent hardware problems that cause local congestion problems, it becomes even more important to have sophisticated network management systems to be able to isolate the problem and cause it to be fixed. One solution in this space would be to have RTP mixers scattered around that would be able to segement the RTP session into manageable segments, and have that mixer be able to adjust quickly to a smaller (say, 2000 home) set by scaling back the video. However, this solution is very unattractive. The benefit of using Multicast IP is that you don't have to put any other software in the router/distribution network. If we require RTP mixers as well, we have to leverage Cisco or another company to provide and propigate those bits throughout parts of the network. M-IP still creates value by keeping track of the routing problems, and allowing RTP sub-sessions to cross multiple routers. It wouldn't be a terrible solution, and would be in line with the RTP philosophy. But unattractive. Part of the scalebility problem is keeping track of the network management in order to become a congestion-avoidant protocol. I'm not sure we can abandon RTCP without a different network management solution in mind. RSVP springs to mind, but, of course, it only solves a subset of the problem since it reserves resources in routers, not wires. I think this is a great challange facing RTP, not a fatal flaw. I look forward to further discussion on the topic. -brianb Technical Project Lead brianb@navio.com From rem-conf-request@es.net Fri Nov 15 19:41:13 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Fri, 15 Nov 1996 16:40:34 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA21682; Fri, 15 Nov 1996 16:40:29 -0800 Date: Fri, 15 Nov 1996 16:40:28 -0800 (PST) From: Stephen Casner To: rem-conf@es.net Subject: Re: RTCP RR's In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Somehow I managed to delete the second half of my message about RTCP. I've tried to reconstruct it here, but it was better the first time. Oh, well. In the first half, I gave some history of the RTCP design and how it was expected to be used. Now, as the number of applications using RTP expands, three concerns have been raised: - privacy of reception - convergence time and memory usage for report interval calculation - using even 5% of the bandwidth for RTCP on low-speed lines One "solution" is to not send RTCP feedback at all. If the receiver emits no RTP/RTCP packets at all, then SSRC id collision is moot so no RTCP BYE need be sent for that purpose, either. This may be appropriate for unidirectional transmission systems or channels that are "guaranteed" by some mechanism. But I wonder about claims that an application does not care about feedback on reception quality; if neither the sender nor receiver cares how much of the data gets through, what's the point of sending it? What I particularly want to avoid is the deletion of RTCP when feedback really is needed, and its replacement with something like SNMP polling of all the receivers which would be far less efficient and effective. A second option, for the single-sender broadcast scenario, is for the receivers to send unicast RTCP to the sender, as Mark Handley and others have proposed. However, it is imperative to avoid the trap of sending the reports at a fixed rate because someone is bound to use the application with a larger number of particiants than anticipated. An alternative is for the sender could control the receiver report rate through an extension such as a new RTCP packet type. There could be problems with the startup dynamics of this scheme, too: if the sender's initial estimate of the receiver population is low, and the number of receivers increases rapidly due to startup synchronized by some external event, the sender could be flooded before it had a chance to tell the receivers to slow down. For either of these options, the receivers need to know that they should behave differently than the default. For some applications, the choice may be implicit, but for RTP implementations that can interoperate in multiple scenarios, the desired behavior would probably have to be specified by an additional SDP session parameter or the like. When RTCP is multicast, encryption of some or all of the RTCP packets, as shown in figure 4 of the RTP spec, may provide appropriate privacy if traffic analysis is not an issue. The key management might be complicated, but it does allow the feedback to be seen where desired and not elsewhere. Note that sending the RTCP packets via unicast does not assure privacy because unicast packets can be snooped, too. Bottom line questions: - Are changes required in the wording of the RTP spec with regard to RTCP usage, and if so, what should the wording be? - How much algorithm detail should be given in the appendices? Section 6.2 describes the goals of the RTCP interval calculation without constraining it to a particular algorithm, then an example algorithm is given in appendix 7. Christian Huitema mentioned some of the more advanced techniques that were discussed during the RTP design, but we decided to include only the basic algorithm in the appendix because that's what was implemented and understood. IETF protocol specs are not supposed to prescribe the implementation. - What other protocols might need changes to support changes we're discussing here? For example, additions to SDP to indicate the RTCP mode. -- Steve From rem-conf-request@es.net Sun Nov 17 01:45:28 1996 Received: from INET-02-IMC.microsoft.com (actually mail2.microsoft.com) by osi-east.es.net with ESnet SMTP (PP); Sat, 16 Nov 1996 22:44:54 -0800 Received: by INET-02-IMC.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BBD40F.C8491010@INET-02-IMC.microsoft.com>; Sat, 16 Nov 1996 22:44:53 -0800 Message-ID: From: Thomas Pfenning To: 'Stephen Casner' , "'rem-conf@es.net'" Subject: RE: RTCP RR's Date: Sat, 16 Nov 1996 22:45:28 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 92 TEXT I think we should add a usage of RTCP which allows large auditorium style conferences on today's typical 28.800 dialup networks. A sender controlled throttling of messages is one good option. While going over the benefits of RTCP messages in large auditoriums I came along another idea. You might not interested in all the individual participants and reception qualities. From an operational perspective you still want to know when things are going wrong and you are doomed to take 5000 service calls. So another option would be a stream property that specifies only to send reports when the reception quality drops below a certain level. That reduces traffic dramatically. Cheers Thomas >-----Original Message----- >From: Stephen Casner [SMTP:casner@precept.com] >Sent: Friday, November 15, 1996 4:40 PM >To: rem-conf@es.net >Subject: Re: RTCP RR's > >Somehow I managed to delete the second half of my message about RTCP. >I've tried to reconstruct it here, but it was better the first time. >Oh, well. In the first half, I gave some history of the RTCP design >and how it was expected to be used. Now, as the number of >applications using RTP expands, three concerns have been raised: > > - privacy of reception > - convergence time and memory usage for report interval calculation > - using even 5% of the bandwidth for RTCP on low-speed lines > >One "solution" is to not send RTCP feedback at all. If the receiver >emits no RTP/RTCP packets at all, then SSRC id collision is moot so >no RTCP BYE need be sent for that purpose, either. This may be >appropriate for unidirectional transmission systems or channels that >are "guaranteed" by some mechanism. But I wonder about claims that >an application does not care about feedback on reception quality; if >neither the sender nor receiver cares how much of the data gets >through, what's the point of sending it? What I particularly want to >avoid is the deletion of RTCP when feedback really is needed, and its >replacement with something like SNMP polling of all the receivers >which would be far less efficient and effective. > >A second option, for the single-sender broadcast scenario, is for the >receivers to send unicast RTCP to the sender, as Mark Handley and >others have proposed. However, it is imperative to avoid the trap of >sending the reports at a fixed rate because someone is bound to use >the application with a larger number of particiants than anticipated. >An alternative is for the sender could control the receiver report >rate through an extension such as a new RTCP packet type. There >could be problems with the startup dynamics of this scheme, too: if >the sender's initial estimate of the receiver population is low, and >the number of receivers increases rapidly due to startup synchronized >by some external event, the sender could be flooded before it had a >chance to tell the receivers to slow down. > >For either of these options, the receivers need to know that they >should behave differently than the default. For some applications, >the choice may be implicit, but for RTP implementations that can >interoperate in multiple scenarios, the desired behavior would >probably have to be specified by an additional SDP session parameter >or the like. > >When RTCP is multicast, encryption of some or all of the RTCP >packets, as shown in figure 4 of the RTP spec, may provide >appropriate privacy if traffic analysis is not an issue. The key >management might be complicated, but it does allow the feedback to be >seen where desired and not elsewhere. Note that sending the RTCP >packets via unicast does not assure privacy because unicast packets >can be snooped, too. > >Bottom line questions: > > - Are changes required in the wording of the RTP spec with regard > to RTCP usage, and if so, what should the wording be? > > - How much algorithm detail should be given in the appendices? > Section 6.2 describes the goals of the RTCP interval calculation > without constraining it to a particular algorithm, then an > example algorithm is given in appendix 7. Christian Huitema > mentioned some of the more advanced techniques that were > discussed during the RTP design, but we decided to include only > the basic algorithm in the appendix because that's what was > implemented and understood. IETF protocol specs are not > supposed to prescribe the implementation. > > - What other protocols might need changes to support changes we're > discussing here? For example, additions to SDP to indicate the > RTCP mode. > -- Steve > From rem-conf-request@es.net Sun Nov 17 20:08:18 1996 Received: from gw.navio.com by osi-east.es.net with ESnet SMTP (PP); Sun, 17 Nov 1996 17:07:30 -0800 Received: (from proxy@localhost) by gw.navio.com (8.6.12/8.6.9) id RAA31907; Sun, 17 Nov 1996 17:07:26 -0800 Received: from lulu.navio.com(204.182.38.230) by tvsoft.com via smap (V1.3) id sma031901; Sun Nov 17 17:07:04 1996 Message-Id: <3.0.32.19961117170600.006f4ba8@gw.navio.com> X-Sender: brianb@gw.navio.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 17 Nov 1996 17:06:01 -0800 To: 'Stephen Casner' , "'rem-conf@es.net'" From: Brian Bulkowski Subject: RE: RTCP RR's Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 10:45 PM 11/16/96 -0800, you wrote: >I think we should add a usage of RTCP which allows large auditorium >style conferences on today's typical 28.800 dialup networks. > >A sender controlled throttling of messages is one good option. While >going over the benefits of RTCP messages in large auditoriums I came >along > another idea. You might not interested in all the individual .. >that specifies only to send reports when the reception quality drops >below a certain level. That reduces traffic dramatically. However, it's a congestion-unfriendly mechanism. If a link hits congestion point, a flood of traffic is generated. Bad. It's hard to get around congestion-unfriendlyness in RTP. For example, currently RTCP is congestion unfriendly. If you have a congested link, you'll think there are fewer other listeners, and start sending more packets. Which is why there's a lot of damping: you have to not hear from an SSRC for quite a while to remove it from the list. In order to get around my client-side memory allocation problem, it would be reasonable for the server to generate the rate of RTCP packets it would like to see in return. This could go in the SR packet (thus be different for each sender). Applications that start seeing large RTCP flows, or know they are on limited-uplink networks, or have an out-of-band method for number-of-client estimation, could request a very small portion, or even no RTCP packets. This would vastly simplify the non-sender memory requirements. It would slightly increase code complexity because you'd have a different RR rate for every Sender, so you'd have to juggle that, which might decrease the cases where you'd get multiple RR fields in an RR packet. It does mean that of multiple senders, only one might generate RRs, for network/link management purposes. It's still congestion unfriendly in the way point out above, and shares all the usual RTP problems when a large RTP stream hits either a distant congested link, or a asymetric link. But it solves at least part of my problem. Of course, you fellas must have thought of it when writing the original spec. So there must be something wrong with it. What? Cheers, brianb From rem-conf-request@es.net Sun Nov 17 21:26:09 1996 Received: from INET-05-IMC.itg.microsoft.com (actually mail5.microsoft.com) by osi-east.es.net with ESnet SMTP (PP); Sun, 17 Nov 1996 18:25:34 -0800 Received: by INET-05-IMC.itg.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BBD4B5.374DDF40@INET-05-IMC.itg.microsoft.com>; Sun, 17 Nov 1996 18:29:06 -0800 Message-ID: From: Thomas Pfenning To: 'Brian Bulkowski' , "'rem-conf@es.net'" Subject: RE: RTCP RR's Date: Sun, 17 Nov 1996 18:26:20 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 67 TEXT The RTP spec does not look like it was done with 28.800 dial up lines in mind. But you are right, the algorithm to report high packet loss should report this within either the 5% or a rate specified by the server. If you want to throttle a bit more a client could wait for a random period until it sends its report and cancel the message if it is seeing a message from the same network/netmask. I have not thought about optimizing this for dialup servers. Thanks for the feedback. Cheers Thomas >-----Original Message----- >From: Brian Bulkowski [SMTP:brianb@navio.com] >Sent: Sunday, November 17, 1996 5:06 PM >To: 'Stephen Casner'; 'rem-conf@es.net' >Subject: RE: RTCP RR's > >At 10:45 PM 11/16/96 -0800, you wrote: >>I think we should add a usage of RTCP which allows large auditorium >>style conferences on today's typical 28.800 dialup networks. >> >>A sender controlled throttling of messages is one good option. While >>going over the benefits of RTCP messages in large auditoriums I came >>along > > >> another idea. You might not interested in all the individual >.. >>that specifies only to send reports when the reception quality drops >>below a certain level. That reduces traffic dramatically. > >However, it's a congestion-unfriendly mechanism. If a link hits congestion >point, a flood of traffic is generated. Bad. > >It's hard to get around congestion-unfriendlyness in RTP. For example, >currently RTCP is congestion unfriendly. If you have a congested link, >you'll think there are fewer other listeners, and start sending more >packets. Which is why there's a lot of damping: you have to not hear from >an SSRC for quite a while to remove it from the list. > >In order to get around my client-side memory allocation problem, it would >be reasonable for the server to generate the rate of RTCP packets it would >like to see in return. This could go in the SR packet (thus be different >for each sender). Applications that start seeing large RTCP flows, or know >they are on limited-uplink networks, or have an out-of-band method for >number-of-client estimation, could request a very small portion, or even no >RTCP packets. This would vastly simplify the non-sender memory >requirements. It would slightly increase code complexity because you'd have >a different RR rate for every Sender, so you'd have to juggle that, which >might decrease the cases where you'd get multiple RR fields in an RR >packet. It does mean that of multiple senders, only one might generate RRs, >for network/link management purposes. > >It's still congestion unfriendly in the way point out above, and shares all >the usual RTP problems when a large RTP stream hits either a distant >congested link, or a asymetric link. But it solves at least part of my >problem. > >Of course, you fellas must have thought of it when writing the original >spec. So there must be something wrong with it. What? > >Cheers, >brianb > From rem-conf-request@es.net Mon Nov 18 06:17:38 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Mon, 18 Nov 1996 03:16:46 -0800 Received: from speedy.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 18 Nov 1996 11:13:19 +0000 To: "Prof. Henning Schulzrinne" cc: Christiaan Balke , rem-conf@es.net Subject: Re: Mbone toolset integration, SDR In-reply-to: Your message of "Fri, 15 Nov 1996 11:18:13 EST." <328C97C5.794BDF32@cs.columbia.edu> Date: Mon, 18 Nov 1996 11:13:23 +0000 Message-ID: <2542.848315603@cs.ucl.ac.uk> From: Colin Perkins --> "Prof. Henning Schulzrinne" writes: >Christiaan Balke wrote: >> The question is about the "Conference Bus" as described in the >> article: >> "vic: A flexible framework for packet video" :1995 >> >> In section 4.6 it is said that the LBL group is working on an >> integrated >> interface for a set of mbone tools. This idea is very usefull in our >> project. At the moment a conference session uses a whole screen full >> with windows from standalone applications and we are thinking of >> writing a common user interface for a (more or less) complete set of >> tools (audio, video, whiteboard). It would help us a great deal if we >> could use what is already available. >> Does anybody know some more of this project and how it is working? Not sure about the LBL folks, but here at UCL we're working on adding conference bus support to RAT, with the aim of allowing easy integration of the tool into a unified user interface (son of the ReLaTe project [1]), and to allow remote control of the tool. It is our desire to make this compatible with future versions of vic/vat/etc... This should be in later versions of RAT-v3.0.x, which should be available in a few months. >> We are also looking for the source code of SDR. Any Pointers? ftp://cs.ucl.ac.uk/mice/sdr/ Regards, Colin [1] http://www-mice.cs.ucl.ac.uk/relate.html From rem-conf-request@es.net Mon Nov 18 17:55:16 1996 Received: from itd.nrl.navy.mil by osi-east.es.net with ESnet SMTP (PP); Mon, 18 Nov 1996 14:53:42 -0800 Received: from [132.250.92.68] (gumbo.itd.nrl.navy.mil) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA27789; Mon, 18 Nov 96 17:53:31 EST Message-Id: <9611182253.AA27789@itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Nov 1996 17:53:41 -0400 To: rem-conf@es.net From: macker@itd.nrl.navy.mil (Joseph P. Macker) Subject: IMM 3.5a1 Alpha Release and Test Cc: wkd@hawaii.edu Hello All: There is a new release, imm3.5a1, of the IMM reliable image dissemination application available at ftp://ftp.hawaii.edu/paccom/imm-3.5a1. IMM3.5a1 has been redesigned to include a number of new features. There is an sdr plug-in included which needs to be installed and will show up under media as image when sdr is launched. Presently binaries are available for a few platforms (irix, solaris, netbsd). Source is now available on the site also. SunOS should build with the Makefile provided. This code is not compatible with previous versions of IMM so please make sure the latest versions of imm and immserv are in your path. USUAL WARNING STUFF: The source code is alpha code and bug reports and porting assistance to presently unsupported platforms would be appreciated. It will also most likely change frequently over the next few months. xv and/or xloadimage are presently required for display of compressed image files or you can provide your own postprocessor desired if desired or just turn on archiving. While IMM is a generic reliable multicast file dissemination application, it presently will not launch from sdr without xv or xloadimage resident locally. This will be modified in a future release. See http://tonnant.itd.nrl.navy.mil/ipresearch/imm.html for more info. An initial MBone test session will be announced on sdr between now and 10am US EST tomorrow Tuesday, Nov 18, 1996 as "IMM 3.5a1 Test". This initial test should extend for a few days with around a 15 minute period between file updates. An Internet Draft of the informational type has been put out as ftp://ds.internic.net/internet-drafts/draft-macker-mdp-framework-00.txt. Thanks, -joe From rem-conf-request@es.net Mon Nov 18 20:14:32 1996 Received: from hosim.kwangju.ac.kr (actually 202.30.35.43) by osi-east.es.net with ESnet SMTP (PP); Mon, 18 Nov 1996 17:13:10 -0800 Received: from vclab.kwangju.ac.kr ([203.230.110.213]) by hosim.kwangju.ac.kr (8.7.1H1/8.7.1) with SMTP id KAA24541 for ; Tue, 19 Nov 1996 10:13:27 -0800 (PST) Message-ID: <3291098A.714C@honey.kwangju.ac.kr> Date: Tue, 19 Nov 1996 10:12:42 +0900 From: Jeongmin Cho Reply-To: com3298@honey.kwangju.ac.kr Organization: Dept. of computer science Kwangju University X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: Help me !!! Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Hello ! I am a graduate student, at Kwangju university. I have studied up on the multimedia synchronization. I am reading a paper on the synchronization. i.g., "Issues in Designing a Transport Protocol for Audio and Video Conference and other Multiparticipant Real-Time Applications." I want to read papers of following. 1) C.J.Sreenan "Synchronization services for continuous media: an experimental evaluation", technical memorandum, AT&T Bell Laboratories, Murray Hill, NJ, Sept. 1993. 2) W.A.Montgomery, "Techniques fo packet voice synchronization", IEEE Journal on Selected Areas in Communication, vol. SAC-1, Dec. 1983 3) D.Cohen, "A protocol for packet-switching voice communication", Computer Network, Vol. 2, September/October 1978. 4) D.P Anderson an G.Homsy, "A Continuous Media I/O Server and its Synchronization Mechanism", IEEE Computer, Vol 32. No.10, Oct.1991 5) L.Ehley, M.Llyas and B.Furht, "A Survey of Multimedia Synchronization Techniques", IEEE Computer Society Press. But, I can't get this papers on Internet. Please, give me a method or location that take these on Internet .. Thank for me. Have a nice day !! -------------------------------------------------------------------- _/ _/ _/_/ _/ Video Communication Laboratory, _/ _/ _/ _/ Kwangju University _/ _/ _/ _/ mailto:com3298@honey.kwangju.ac.kr _/ _/_/ _/_/_/ 502-703 592-1 Jinwol-dong Namgu, Kwangju in Korea. Dept. of Computer science Tel: 062-670-2386 Fax: 062-670-2187 -------------------------------------------------------------------- From rem-conf-request@es.net Mon Nov 18 21:17:20 1996 Received: from nobozo.CS.Berkeley.EDU by osi-east.es.net with ESnet SMTP (PP); Mon, 18 Nov 1996 18:16:13 -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 SAA07254 for ; Mon, 18 Nov 1996 18:16:13 -0800 Date: Mon, 18 Nov 1996 18:16:13 -0800 Message-Id: <199611190216.SAA07254@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] U.C. Berkeley Multimedia & Graphics Seminar Wednesday November 20, 1996 12:30-2:00 PDT 405 Soda Hall "The Visual Instruction Set" Robert Yung Sun Microsystems Laboratories MBONE BRAODCAST BEGINS AT 12.40 PDT (GMT - 8 HRS.) From rem-conf-request@es.net Mon Nov 18 22:41:29 1996 Received: from broon.off.connect.com.au by osi-east.es.net with ESnet SMTP (PP); Mon, 18 Nov 1996 19:40:11 -0800 Received: from connect.com.au (ggm@localhost) by broon.off.connect.com.au with ESMTP id NAA13320 (8.7.6h/IDA-1.6); Tue, 19 Nov 1996 13:39:19 +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: macker@itd.nrl.navy.mil (Joseph P. Macker) cc: rem-conf@es.net, wkd@hawaii.edu Subject: Re: IMM 3.5a1 Alpha Release and Test In-reply-to: Your message of "Mon, 18 Nov 1996 17:53:41 -0400." <9611182253.AA27789@itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Nov 1996 13:39:16 +1000 Message-ID: <13319.848374756@connect.com.au> From: George Michaelson Joe, can you give an indication of what application level concepts you see the new IMM being viable for? The web references are protocol specs and don't hint at what you see "file and directory replication" being useful for. I am kinda hoping you've got some specific apps in mind like www replication, cache replication, batched news update... -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 Tue Nov 19 06:58:18 1996 Received: from dxmint.cern.ch by osi-east.es.net with ESnet SMTP (PP); Tue, 19 Nov 1996 03:57:46 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id MAA26265; Tue, 19 Nov 1996 12:57:01 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA08076; Tue, 19 Nov 1996 12:57:01 +0100 Message-Id: <9611191157.AA08076@dxcoms.cern.ch> Subject: MBONE announcement for CERN ATLAS Plenary meetings To: rem-conf@es.net, hepnet-l@slacvm.slac.stanford.edu, hrc@frcpn11.in2p3.fr, htasc@listbox.cern.ch, net-teleconferencing@listbox.cern.ch Date: Tue, 19 Nov 1996 12:57:00 +0100 (MET) From: Martin Fluckiger - CERN/CN/CS Cc: fle@dxcoms.cern.ch (Martin Fluckiger) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit CERN is pleased to announce the MBONE broadcast of the ATLAS Physics working group meeting and Plenary meetings -------------------------------------------------------- on Thursday/Friday 28/29 November 1996 from the CERN Auditorium Provisional Agenda: ------------------- >>> Times are UTC+2 <<< Thursday 28 November 1996 ------------------------- 09h00 Physics working group Plenary meeting I 14:00 Introduction, status and general issues (P Jenni) 14:30 LHCC matters and status of TDRs (T Akesson) 15:00 Inner detector issues 16:00 --- tea break --- 16:30 Computing Technical Proposal, status and critical issues - computing model (A Schaffer) - software (K Bos) - general status (J Knobloch) 17:30 Trigger/DAQ progress report - status of the level-2 trigger (M Abolins) 18:15 --- end of part I --- Friday 29 November 1996 ----------------------- Plenary meeting II 8:30 Technical co-ordination issues - EDMS pilot project report (F Dittus) - progress on experimental area (G Kantardjian) - delivery dates for installation (H Hoffmann) - integration and crack/gap (H Hoffmann) 9:45 EB composition and subsystem organization follow-up discussion (P Jenni) 10:15 --- coffee break --- 10:45 Tile calorimeter status (critical issues for the TDR, including the plug calorimeter and gap scintillator) () 11:15 LAr calorimeter status (critical issues for the TDR, including the preamplifier choice for the hadronic end-caps and access to the EM barrel vs soleniod services) () 12:00 Muon spectrometer progress report () 12:50 Next meetings 12:55 --- end of part II --- The broadcast is announced via sdr as "CERN ATLAS". vat and vic applications will be used with a ttl of 127. In case of questions or problems please contact . This message is sent to distribution lists, sorry if you receive multiple copies of it. Best regards, -------------------------------------------------------------------- Martin Fluckiger & Christian Isnard CERN - CN/CS/EN multicast@noc.cern.ch European Laboratory for Particle Physics Computers and Networks division CH-1211 Geneva 23 - Switzerland From rem-conf-request@es.net Tue Nov 19 10:35:12 1996 Received: from itd.nrl.navy.mil by osi-east.es.net with ESnet SMTP (PP); Tue, 19 Nov 1996 07:34:37 -0800 Received: from [132.250.92.68] (gumbo.itd.nrl.navy.mil) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA21586; Tue, 19 Nov 96 10:34:29 EST Message-Id: <9611191534.AA21586@itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Nov 1996 10:34:39 -0400 To: George Michaelson From: macker@itd.nrl.navy.mil (Joseph P. Macker) Subject: Re: IMM 3.5a1 Alpha Release and Test Cc: rem-conf@es.net, wkd@hawaii.edu At 1:39 PM 11/19/96 +1000, George Michaelson wrote: >Joe, can you give an indication of what application level concepts you >see the new IMM being viable for? The web references are protocol specs >and don't hint at what you see "file and directory replication" being >useful for. > >I am kinda hoping you've got some specific apps in mind like www replication, >cache replication, batched news update... > >-George Well, the framework underlying IMM3.5a1 is straightforward and has the ability to support generic reliable multicast file transfer, so it could be used in numerous contexts. Those who remember and used IMM in the early MBone probably were not sure what was under the hood (other than they got nice hourly global satellite weather updates). Winston and I improved the design some, put some hooks for more generic usage and submitted the Internet Draft as a historical/informational piece. I think the services you mentioned are some examples of good possibilities for application. Its design strength is more oriented towards the support of bulk transfer. I'd like to see some other experimental uses of the code so please take it and run with it. Using a browser or a MIME aware application as a post processor would be nice. We do have plans to add more features along those lines ourselves (e.g, like the present user defined post processor), but I'd like to get a set of alpha tests under our belt with this release. Some of my future ideas include potential hybrid FEC/ARQ operation for high error rate, streaming, or asymmetric multicast internetwork scenarios. In my user community people are disseminating large files (e.g., Powerpoint docs, MIME format) around a workgroup using good old unicast. I'd like to give them a multicast-oriented reliable file dissemination tool that's network friendly. -joe From rem-conf-request@es.net Tue Nov 19 12:13:38 1996 Received: from aruba.lerc.nasa.gov by osi-east.es.net with ESnet SMTP (PP); Tue, 19 Nov 1996 09:12:50 -0800 Received: from captiva.lerc.nasa.gov by aruba.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id MAA15173; Tue, 19 Nov 1996 12:11:25 -0500 (EST) Received: from jmudry1.lerc.nasa.gov by captiva.lerc.nasa.gov with SMTP (NASA LeRC 8.7.4.1/2.01-local) id MAA17278; Tue, 19 Nov 1996 12:11:04 -0500 (EST) Message-Id: <2.2.32.19961119171102.006e2dec@popserve.lerc.nasa.gov> X-Info: IDE / NASA Lewis Research Center X-Sender: prmudry@popserve.lerc.nasa.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Nov 1996 12:11:02 -0500 To: chiueh@cs.sunysb.edu, chlamtac@BCN.BU.EDU, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, danzig@pollux.usc.edu, dbarbara@bellcore.com, dboff@ddn-pac.ddn.mil, dbworld@cs.wisc.edu, eddie.hsu@jpl.nasa.gov, end2end-interest@isi.edu, epitoura@cc.uoi.gr, f-troup@aurora.cis.upenn.edu, grossman@uic.edu, helm@seas.gwu.edu, hfk@research.att.com, hipparch@sophia.inria.fr, ian@cesdis1.gsfc.nasa.gov, ieeetcpc@ccvm.sunysb.edu, jimf@aro.nctu.edu.tw, mhd@seas.smu.edu, mobile-ip@Tadpole.com, msmith@osat.hq.nasa.gov, nishida@dc.kdd.com, padmanab@joyride.CS.Berkeley.EDU, pat.gary@gsfc.nasa.gov, ralonso@peanut.sarnoff.com, randy@cs.Berkeley.edu, rem-conf@es.net, reres@laas.fr, rgopal@hns.com, rhoward@sses2.cta.com From: John J Mudry INVITATION ANNOUNCEMENT The NASA Lewis Research Center in conjunction with the Radiological Society of North America's (RSNA) Scientific assembly and annual meeting will hold a workshop entitled: "COMMUNICATIONS SERVICES FOR THE 21st CENTURY: AN INFORMATION EXCHANGE" TUESDAY - December 3, 1996 5:30 PM - 7:30 PM AT: McCormick Place - Chicago, IL Meeting Room N227 The agenda for this forum includes a panel discussion among commercial satellite companies, representatives from terrestrial communications service providers, and professionals from the medical/telemedicine community. Questions and answers and networking opportunities will follow the panel discussion. Attendees have the opportunity to learn about the advanced communications satellite systems and services being developed by U.S. companies. You will learn about the potential of hybrid (satellite/terrestrial) networks and their amazing ability to move large amounts of digital data interactively at high speed to virtually anywhere on-demand! As innovators of telemedicine applications, the Advanced Communications Technology Satellite (ACTS)medical experimenters will present their views of communication requirements necessary to further implement telemedical services. Your immediate response to attend the "COMMUNICATIONS SERVICES FOR THE 21st CENTURY: AN INFORMATION EXCHANGE" is requested. Please contact one of the following individuals no later than close-of-business Monday, November 25, 1996. John Mudry Jennifer Sibits Phone: 216 433-2149 Phone: 216 433-8142 Fax: 216 433-6371 Fax: 216 433-6371 email: jmudry@lerc.nasa.gov email: j.sibits@lerc.nasa.gov Passes to this event are limited and include both the workshop and one-day access 12/3/96 to RSNA's InfoRAD Exhibit. (Those already registered with RSNA do not need to request a pass for this event, however, please let us know you're coming. From rem-conf-request@es.net Tue Nov 19 12:47:03 1996 Received: from aruba.lerc.nasa.gov by osi-east.es.net with ESnet SMTP (PP); Tue, 19 Nov 1996 09:46:17 -0800 Received: from captiva.lerc.nasa.gov by aruba.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id MAA16651; Tue, 19 Nov 1996 12:41:52 -0500 (EST) Received: from jmudry1.lerc.nasa.gov by captiva.lerc.nasa.gov with SMTP (NASA LeRC 8.7.4.1/2.01-local) id MAA23017; Tue, 19 Nov 1996 12:41:50 -0500 (EST) Message-Id: <2.2.32.19961119174147.006fb6d0@popserve.lerc.nasa.gov> X-Info: IDE / NASA Lewis Research Center X-Sender: prmudry@popserve.lerc.nasa.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Nov 1996 12:41:47 -0500 To: chiueh@cs.sunysb.edu, chlamtac@BCN.BU.EDU, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, danzig@pollux.usc.edu, dbarbara@bellcore.com, dboff@ddn-pac.ddn.mil, dbworld@cs.wisc.edu, eddie.hsu@jpl.nasa.gov, end2end-interest@isi.edu, epitoura@cc.uoi.gr, f-troup@aurora.cis.upenn.edu, grossman@uic.edu, helm@seas.gwu.edu, hfk@research.att.com, hipparch@sophia.inria.fr, ian@cesdis1.gsfc.nasa.gov, ieeetcpc@ccvm.sunysb.edu, jimf@aro.nctu.edu.tw, mhd@seas.smu.edu, mobile-ip@Tadpole.com, msmith@osat.hq.nasa.gov, nishida@dc.kdd.com, padmanab@joyride.CS.Berkeley.EDU, pat.gary@gsfc.nasa.gov, ralonso@peanut.sarnoff.com, randy@cs.Berkeley.edu, rem-conf@es.net, reres@laas.fr, rgopal@hns.com, rhoward@sses2.cta.com From: John J Mudry Subject: MEETING INVITATION INVITATION ANNOUNCEMENT The NASA Lewis Research Center in conjunction with the Radiological Society of North America's (RSNA) Scientific assembly and annual meeting will hold a workshop entitled: "COMMUNICATIONS SERVICES FOR THE 21st CENTURY: AN INFORMATION EXCHANGE" TUESDAY - December 3, 1996 5:30 PM - 7:30 PM AT: McCormick Place - Chicago, IL Meeting Room N227 The agenda for this forum includes a panel discussion among commercial satellite companies, representatives from terrestrial communications service providers, and professionals from the medical/telemedicine community. Questions and answers and networking opportunities will follow the panel discussion. Attendees have the opportunity to learn about the advanced communications satellite systems and services being developed by U.S. companies. You will learn about the potential of hybrid (satellite/terrestrial) networks and their amazing ability to move large amounts of digital data interactively at high speed to virtually anywhere on-demand! As innovators of telemedicine applications, the Advanced Communications Technology Satellite (ACTS)medical experimenters will present their views of communication requirements necessary to further implement telemedical services. Your immediate response to attend the "COMMUNICATIONS SERVICES FOR THE 21st CENTURY: AN INFORMATION EXCHANGE" is requested. Please contact one of the following individuals no later than close-of-business Monday, November 25, 1996. John Mudry Jennifer Sibits Phone: 216 433-2149 Phone: 216 433-8142 Fax: 216 433-6371 Fax: 216 433-6371 email: jmudry@lerc.nasa.gov email: j.sibits@lerc.nasa.gov Passes to this event are limited and include both the workshop and one-day access 12/3/96 to RSNA's InfoRAD Exhibit. (Those already registered with RSNA do not need to request a pass for this event, however, please let us know you're coming. From rem-conf-request@es.net Tue Nov 19 13:05:46 1996 Received: from central.bldrdoc.gov by osi-east.es.net with ESnet SMTP (PP); Tue, 19 Nov 1996 10:05:02 -0800 Received: from sun.bldrdoc.gov (sun [132.163.10.10]) by central.bldrdoc.gov (8.6.13/8.6.11) with SMTP id LAA16344 for ; Tue, 19 Nov 1996 11:05:02 -0700 Received: by sun.bldrdoc.gov (5.x/SMI-SVR4) id AA00431; Tue, 19 Nov 1996 11:13:54 -0700 Date: Tue, 19 Nov 1996 11:13:54 -0700 From: sting@boulder.nist.gov (Michael Ting) Message-Id: <9611191813.AA00431@sun.bldrdoc.gov> To: rem-conf@es.net Subject: question on sdr's recording button X-Sun-Charset: US-ASCII When I chose sdr's record button to record a session, I got the following error window - ----- Error in Tcl Script Error: Couldn't execute "record_session": no such file or directory ------------ Any idea? Thanks! Michael Ting, NIST Boulder From rem-conf-request@es.net Tue Nov 19 16:43:43 1996 Received: from elausrv1.att.net.au by osi-east.es.net with ESnet SMTP (PP); Tue, 19 Nov 1996 13:42:54 -0800 Received: from [202.10.0.154] ([202.10.0.154]) by elausrv1.att.net.au (8.7.1/AT&T-EasyLink-Australia-V1) with ESMTP id IAA05193; Wed, 20 Nov 1996 08:41:22 +1100 (EST) X-Sender: kpage@mail.att.net.au (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Nov 1996 08:44:15 +1100 To: rem-conf@es.net, hepnet-l@slacvm.slac.stanford.edu, hrc@frcpn11.in2p3.fr, htasc@listbox.cern.ch, net-teleconferencing@listbox.cern.ch From: Kevin Page Subject: FREE ONLINE AUSTRALIAN IMAGE LIBRARY PRESS RELEASE FREE ONLINE AUSTRALIAN IMAGE LIBRARY http://www.imagenet.com.au Local web production studio, neural.com, have recently launched a new World Wide Web site which has the potential to dramatically change the way in which people search for, use and procure photographic images. ImageNet is an online image library which specialises in Australian content. The majority of the images within the database have a distinct bias towards Australian flora and fauna, landscapes, textures, backgrounds and the Australian environment in general. The images are high quality, having been shot professionally, drum scanned with no unsharp masking applied and are all in four colour. Four colour images (cyan, yellow, magenta and black) are better for print reproduction purposes than RGB (red, green, blue) ones and having no unsharp masking means that they can be easily manipulated digitally. David Will, the Sales and Marketing Manager for neural.com, said that the site was developed with a number of objectives in mind. Firstly, so that anyone developing a web site has easy access to professionally produced photographic images with a distinct Australian flavour. When the low resolution images are downloaded and used within a World Wide Web site they are completely free of any copyright restrictions, financial charges or obligation. Secondly, so that people involved in an industry that requires the construction of layouts for graphical presentations (advertising, marketing, public relations, etc.) can easily obtain photographic images without violating Australian copyright laws. Currently, anyone that produces layouts by scanning from books, magazines, stock library catalogues or just about any other source is in breach of copyright. In most cases, even recycling digital images is against the law. Obviously, this situation does not reflect contemporary work practices, where the wide spread use of desktop digital imaging systems and the explosive growth of image usage on the World Wide Web requires a change in focus. ImageNet gives people the ability to easily access suitable images without having to break the law, sign a contract, flick through magazines, pay someone money, scan, or wait unnecessarily. Lastly, neural.com is hoping that the ImageNet approach will encourage people to buy the high resolution versions of the files. If, for instance, an Art Director uses a low resolution ImageNet file within their presentation and the concept is approved, ImageNet will sell the high resolution file for a 'one off' usage fee of A$250.00, regardless of intended use. This is a radically different approach in that usage rights are traditionally calculated by the size the image is going to appear at, how much exposure it will receive and the length of time it will run. The only additional charges will be to cover the cost of the customer's preferred transfer method. ImageNet will transfer the high resolution file via ISDN, burn the image to CD ROM or copy it to virtually any transfer medium for dispatch, locally or internationally. Initially, contact would have to be made via the site or by telephone to facilitate this but they will shortly be introducing a secure transaction facility to make the process even easier. If site visitors require any additional services such as image retouching, 3D rendering, web site development or print production (colour proofs, transparencies, seperated film, direct to plate printing, etc.) they are directed to linked sites where these services are detailed. Mr. Will says that ImageNet will be constantly adding new images from a variety of Australian photographers to the site and will also be listening to visitors' suggestions on how to improve the experience. With their innovative approach and obvious understanding of the changing requirements of today's imaging professionals, this is one site that is sure to attract more than its share of visitors. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-= Kevin Page BA (Hons) PgD MA | Voice: +61 (2) 9954.0922 | Fax: +61 (2) 9923.2453 NEURAL.COM | ISDN: +61 (2) 9919.7440 Internet Publishing House. | E-mail: kpage@neural.com.au | URL. http://www.neural.com.au 42-44 Victoria Street, McMahons Point, Sydney NSW 2060, Australia. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-= From rem-conf-request@es.net Tue Nov 19 17:06:10 1996 Received: from elausrv1.att.net.au by osi-east.es.net with ESnet SMTP (PP); Tue, 19 Nov 1996 14:04:55 -0800 Received: from [202.10.0.154] ([202.10.0.154]) by elausrv1.att.net.au (8.7.1/AT&T-EasyLink-Australia-V1) with ESMTP id IAA05181; Wed, 20 Nov 1996 08:40:18 +1100 (EST) X-Sender: kpage@mail.att.net.au (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Nov 1996 08:43:08 +1100 To: chiueh@cs.sunysb.edu, chlamtac@BCN.BU.EDU, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, danzig@pollux.usc.edu, dbarbara@bellcore.com, dboff@ddn-pac.ddn.mil, dbworld@cs.wisc.edu, eddie.hsu@jpl.nasa.gov, end2end-interest@isi.edu, epitoura@cc.uoi.gr, f-troup@aurora.cis.upenn.edu, grossman@uic.edu, helm@seas.gwu.edu, hfk@research.att.com, hipparch@sophia.inria.fr, ian@cesdis1.gsfc.nasa.gov, ieeetcpc@ccvm.sunysb.edu, jimf@aro.nctu.edu.tw, mhd@seas.smu.edu, mobile-ip@Tadpole.com, msmith@osat.hq.nasa.gov, nishida@dc.kdd.com, padmanab@joyride.CS.Berkeley.EDU, pat.gary@gsfc.nasa.gov, ralonso@peanut.sarnoff.com, randy@cs.Berkeley.edu, rem-conf@es.net, reres@laas.fr, rgopal@hns.com, rhoward@sses2.cta.com From: Kevin Page Subject: FREE ONLINE AUSTRALIAN IMAGE LIBRARY PRESS RELEASE FREE ONLINE AUSTRALIAN IMAGE LIBRARY http://www.imagenet.com.au Local web production studio, neural.com, have recently launched a new World Wide Web site which has the potential to dramatically change the way in which people search for, use and procure photographic images. ImageNet is an online image library which specialises in Australian content. The majority of the images within the database have a distinct bias towards Australian flora and fauna, landscapes, textures, backgrounds and the Australian environment in general. The images are high quality, having been shot professionally, drum scanned with no unsharp masking applied and are all in four colour. Four colour images (cyan, yellow, magenta and black) are better for print reproduction purposes than RGB (red, green, blue) ones and having no unsharp masking means that they can be easily manipulated digitally. David Will, the Sales and Marketing Manager for neural.com, said that the site was developed with a number of objectives in mind. Firstly, so that anyone developing a web site has easy access to professionally produced photographic images with a distinct Australian flavour. When the low resolution images are downloaded and used within a World Wide Web site they are completely free of any copyright restrictions, financial charges or obligation. Secondly, so that people involved in an industry that requires the construction of layouts for graphical presentations (advertising, marketing, public relations, etc.) can easily obtain photographic images without violating Australian copyright laws. Currently, anyone that produces layouts by scanning from books, magazines, stock library catalogues or just about any other source is in breach of copyright. In most cases, even recycling digital images is against the law. Obviously, this situation does not reflect contemporary work practices, where the wide spread use of desktop digital imaging systems and the explosive growth of image usage on the World Wide Web requires a change in focus. ImageNet gives people the ability to easily access suitable images without having to break the law, sign a contract, flick through magazines, pay someone money, scan, or wait unnecessarily. Lastly, neural.com is hoping that the ImageNet approach will encourage people to buy the high resolution versions of the files. If, for instance, an Art Director uses a low resolution ImageNet file within their presentation and the concept is approved, ImageNet will sell the high resolution file for a 'one off' usage fee of A$250.00, regardless of intended use. This is a radically different approach in that usage rights are traditionally calculated by the size the image is going to appear at, how much exposure it will receive and the length of time it will run. The only additional charges will be to cover the cost of the customer's preferred transfer method. ImageNet will transfer the high resolution file via ISDN, burn the image to CD ROM or copy it to virtually any transfer medium for dispatch, locally or internationally. Initially, contact would have to be made via the site or by telephone to facilitate this but they will shortly be introducing a secure transaction facility to make the process even easier. If site visitors require any additional services such as image retouching, 3D rendering, web site development or print production (colour proofs, transparencies, seperated film, direct to plate printing, etc.) they are directed to linked sites where these services are detailed. Mr. Will says that ImageNet will be constantly adding new images from a variety of Australian photographers to the site and will also be listening to visitors' suggestions on how to improve the experience. With their innovative approach and obvious understanding of the changing requirements of today's imaging professionals, this is one site that is sure to attract more than its share of visitors. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-= Kevin Page BA (Hons) PgD MA | Voice: +61 (2) 9954.0922 | Fax: +61 (2) 9923.2453 NEURAL.COM | ISDN: +61 (2) 9919.7440 Internet Publishing House. | E-mail: kpage@neural.com.au | URL. http://www.neural.com.au 42-44 Victoria Street, McMahons Point, Sydney NSW 2060, Australia. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-= From rem-conf-request@es.net Tue Nov 19 17:14:33 1996 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Tue, 19 Nov 1996 14:13:44 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <59213(8)>; Tue, 19 Nov 1996 14:12:11 PST Received: by crevenia.parc.xerox.com id <177557>; Tue, 19 Nov 1996 14:11:25 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=19701020; charset=US-ASCII From: Bill Fenner To: sting@boulder.nist.gov Subject: Re: question on sdr's recording button Cc: rem-conf@es.net Versions: dmail 2.0b/makemail 2.8f Message-Id: <96Nov19.141125pst.177557@crevenia.parc.xerox.com> Date: Tue, 19 Nov 1996 14:11:15 PST --19701020 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename=body00 In message <9611191813.AA00431@sun.bldrdoc.gov> you write: >----- >Error in Tcl Script >Error: Couldn't execute >"record_session": no such file or >directory >------------ You need a "record_session" script. I use this one, which invokes MBone VCR. Bill --19701020 Content-Type: application/x-perl; name="record_session"; x-unix-mode=0755 Content-Disposition: attachment; filename="record_session" #!/import/misc/bin/perl # # record_session # # An interface between sdr and the MBone VCR. # sdr launches this script with an SDP session description as input. # This script creates an MBone VCR .vcr file out of the session description, # and creates a .cmd file that starts recording immediately, and starts # the MBone VCR with the .cmd file on the command line. # # Bill Fenner 22 Apr 1996 # # # Set the next line to the MBone VCR executable location $vcr = "mbone_vcr"; # You should not need to change anything below this line. require 'ctime.pl'; $ver = "0.9"; $fn = $ARGV[0]; $fn =~ s/\.vcr$//; $vcrfn = $fn . ".vcr"; $cmdfn = $fn . ".cmd"; open(VCR,">$vcrfn") || die "$vcrfn: $!\n"; print VCR "\n"; print VCR "# This file was generated by record_session v$ver\n"; print VCR "session_date=", &ctime(time); $medianum = 1; # I don't know if MBone VCR requires any particular ordering of its file. # Given the SDP fields in the order that sdr outputs them, this loop should # create the .vcr file in the same order as MBone VCR does. while () { chop; ($key,$data) = split(/=/,$_,2); if ($key eq "s") { print VCR "session_name=$data\n"; } elsif ($key eq "i") { print VCR "session_desc=$data\n"; } elsif ($key eq "c") { if ($medianame) { ($mediaip,$mediattl) = ($data =~ m|([0-9.]+)/(\d+)$|); } else { ($ip,$ttl) = ($data =~ m|([0-9.]+)/(\d+)$|); if ($ttl) { print VCR "session_max_ttl=$ttl\n"; } else { print VCR "session_max_ttl=0\n"; # XXX } } } elsif ($key eq "m") { if ($medianame) { print VCR "${medianum}=media_port=$mediaport\n"; print VCR "${medianum}=media_ip=$mediaip\n"; print VCR "${medianum}=media_name=$medianame\n"; print VCR "${medianum}=media_type=$mediatype\n"; print VCR "${medianum}=media_mute=0\n"; print VCR "${medianum}=media_desc=$medianame\n"; print VCR "${medianum}=media_cmd=$mediacmd\n"; print VCR "${medianum}=media_cid=$mediacid\n"; print VCR "${medianum}=media_ttl=$mediattl\n"; $medianum++; undef $medianame; } ($medianame, $mediaport, $type, $fmt) = split(/\s+/, $data); $mediacid = 0; undef $mediatype; undef $mediacmd; undef $mediattl; $mediaip = $ip; if ($type eq "vat") { $mediatype = 2; } elsif ($type =~ /^rtp$/io || $type =~ m|^rtp/avp$|io ) { $mediatype = 1; } else { print STDERR "Warning: don't know about media type $type so "; print STDERR "can't record $medianame media...\n"; undef $medianame; next; } if ($medianame eq "audio") { $mediacmd = "vat"; } elsif ($medianame eq "video") { $mediacmd = "vic"; } else { $mediacmd = "unknown"; } } elsif ($key eq "a") { if ($medianame && $data =~ /id:(\d+)/) { $mediacid = $1; } } } if ($medianame) { print VCR "${medianum}=media_port=$mediaport\n"; print VCR "${medianum}=media_ip=$mediaip\n"; print VCR "${medianum}=media_name=$medianame\n"; print VCR "${medianum}=media_type=$mediatype\n"; print VCR "${medianum}=media_mute=0\n"; print VCR "${medianum}=media_desc=$medianame\n"; print VCR "${medianum}=media_cmd=$mediacmd\n"; print VCR "${medianum}=media_cid=$mediacid\n"; print VCR "${medianum}=media_ttl=$mediattl\n"; } close(VCR); open(CMD,">$cmdfn") || die "$cmdfn: $!\n"; print CMD "# Load the session description file\n"; print CMD "load $vcrfn\n"; print CMD "# Just in case we're being asked to add to an existing file\n"; print CMD "goto end\n"; print CMD "# Allow recording\n"; print CMD "rec_enabled on\n"; print CMD "# and start recording immediately!\n"; print CMD "rec\n"; close(CMD); exec "$vcr -c $cmdfn &"; --19701020-- From rem-conf-request@es.net Tue Nov 19 18:31:34 1996 Received: from mercury.lcs.mit.edu by osi-east.es.net with ESnet SMTP (PP); Tue, 19 Nov 1996 15:30:28 -0800 Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id SAA22680; Tue, 19 Nov 1996 18:30:16 -0500 X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: sting@boulder.nist.gov (Michael Ting) cc: rem-conf@es.net Subject: Re: question on sdr's recording button In-reply-to: Your message of "Tue, 19 Nov 96 11:13:54 MST." <9611191813.AA00431@sun.bldrdoc.gov> Date: Tue, 19 Nov 96 18:30:16 -0500 Message-ID: <21536.848446216@mercury.lcs.mit.edu> Sender: mjh@mercury.lcs.mit.edu X-Mts: smtp >When I chose sdr's record button to record a session, I got the >following error window - > >----- >Error in Tcl Script >Error: Couldn't execute >"record_session": no such file or >directory >------------ > >Any idea? Sdr doesn't implement any form of recording, but it has a stub for doing so. It will try to start a script called "record_session", will pass it the SDP description (containing only the media you select) on stdin, and give it the filename you specified as a command line argument. To my knowledge, no-one's ever written an appropriate script to tie in to any of the mbone recording tools. Mark From rem-conf-request@es.net Tue Nov 19 18:34:46 1996 Received: from central.bldrdoc.gov by osi-east.es.net with ESnet SMTP (PP); Tue, 19 Nov 1996 15:33:32 -0800 Received: from sun.bldrdoc.gov (sun [132.163.10.10]) by central.bldrdoc.gov (8.6.13/8.6.11) with SMTP id QAA00125; Tue, 19 Nov 1996 16:33:37 -0700 Received: by sun.bldrdoc.gov (5.x/SMI-SVR4) id AA00528; Tue, 19 Nov 1996 16:42:27 -0700 Date: Tue, 19 Nov 1996 16:42:27 -0700 From: sting@boulder.nist.gov (Michael Ting) Message-Id: <9611192342.AA00528@sun.bldrdoc.gov> To: fenner@parc.xerox.com Subject: Re: question on sdr's recording button Cc: rem-conf@es.net X-Sun-Charset: US-ASCII Bill, > > In message <9611191813.AA00431@sun.bldrdoc.gov> you write: > >----- > >Error in Tcl Script > >Error: Couldn't execute > >"record_session": no such file or > >directory > >------------ > > You need a "record_session" script. I use this one, which invokes > MBone VCR. > Thank you very much for the answer and the script. One further related question - where I might locate a program that takes snapshots of an mbone video session and saves the snapshots as image files for Web posting at fixed time intervals? Thanks again! Michael From rem-conf-request@es.net Wed Nov 20 07:23:38 1996 Received: from ix.future.at (actually franz-josef.future.at) by osi-east.es.net with ESnet SMTP (PP); Wed, 20 Nov 1996 04:22:51 -0800 Received: from franz-josef.future.at (franz-josef.future.at [194.152.163.249]) by ix.future.at (NTMail 3.02.10) with ESMTP id da039211 for ; Wed, 20 Nov 1996 13:22:15 +0000 Message-Id: <3.0b26.32.19961120132209.008db9e0@mail.future.at> X-Sender: root@mail.future.at X-Mailer: Windows Eudora Pro Version 3.0b26 (32) Date: Wed, 20 Nov 1996 13:22:12 +0100 To: shit-list@zz.com, neural@neural.com.au From: Postmaster Subject: Re: FREE ONLINE AUSTRALIAN IMAGE LIBRARY Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Kevin & Fred, >PRESS RELEASE >FREE ONLINE AUSTRALIAN IMAGE LIBRARY Your Australian Image Libraby looks like a GREAT idea! If you want to generate EVEN MORE publicity for it then our list of 100,000 E-Mail addresses is what you need! It's just that simple. What would it cost to send 100,000 letters at .32 cents PER STAMP?? Can you imagine if you got just a 1% response rate? That's over ONE THOUSAND ORDERS!!! Use it as often as you like, over and over. Make the power of the Internet work to your advantage. I'll send you these addresses online with simple instructions that will get you started on your way. For more information visit http://www.phoenix.at/bulk1.html To order: There will be no delay. Get the 100,000 E-Mail addresses ONLINE TODAY for only $35.00! Or get 200,000 for $50.00 <<== LIMITED TIME SPECIAL!! Act now. Just fill in the blanks and send the form below as soon as possible to... office@future.at If you'd prefer sending your order in by fax, our fax number is 1-800-555-9205 ext. 5030. =================================================================== ORDER FORM OK, COUNT ME IN! Please rush me the... [ ] 100,000 E-Mail list at $35.00 [ ] 200,000 E-Mail list at $50.00 <<== LIMITED TIME SPECIAL!! [ ] 900,000 E-Mail list at $150.00 <<== HOT!! OFFER VALID UNTIL NOV. 25th ONLY!! today! Your Name________________________________________________________ Street Address___________________________________________________ City, State, ZIP_________________________________________________ Country__________________________________________________________ Phone ___________________________________________________________ Fax______________________________________________________________ Email____________________________________________________________ [ ] Deliver them online to this email address: ______________________ [ ] Send them on disk to the address above ($10 surcharge) Please charge my credit card the amount of US$ ____,- [ ] VISA [ ] Mastercard [ ] American Express Card #:__________________________________ Exp.:__________________ Name on card:____________________________ Electronic Signature:x___________________ Date:x__________________ =================================================================== To get the E-Mail addresses ONLINE TODAY, send this order form to office@future.at immediately. If you'd prefer sending your order in by fax, our fax number is 1-800-555-9205 ext. 5030. The E-Mail list will be delivered the SAME DAY we receive your order. Thanks for your time, and good luck in all your business efforts! Postmaster The "BuyThemNow" Team From rem-conf-request@es.net Thu Nov 21 10:14:02 1996 Received: from nfs1.inf.rl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Thu, 21 Nov 1996 07:13:22 -0800 Received: from grommit.cis.rl.ac.uk.informatics by nfs1.inf.rl.ac.uk (SMI-8.6/SMI-SVR4) id PAA08227; Thu, 21 Nov 1996 15:07:24 GMT Received: by grommit.cis.rl.ac.uk.informatics (SMI-8.6/SMI-SVR4) id PAA21722; Thu, 21 Nov 1996 15:07:22 GMT Date: Thu, 21 Nov 1996 15:07:22 GMT From: ijj@inf.rl.ac.uk (Ian Johnson) Message-Id: <199611211507.PAA21722@grommit.cis.rl.ac.uk.informatics> To: macker@itd.nrl.navy.mil, rem-conf@es.net Subject: Q: Visualisation over the MBone? (was Re: IMM 3.5a1 Alpha Release and Test) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: yFAbxWP6tRMolfZbpgPT5g== Joseph, Your comments on some of the other uses you are hoping that MDP might be suited for prompt me to ask the list: does anyone have experience of distributing visualisations using reliable multicast? What we're trying to acheive is a way of running a visualisation package (currently AVS, but Iris Explorer is another candidate) between machines. One approach we're trying is to intercept an AVS pipeline at the geometry output stage and send this data to "slave" pipelines on other machines which would then render the geometry. We believe that the geometry output will small in size (a few KB at most). We are looking for reliability (natch) - we can't afford to lose geometry output! If anyone else is in this position, perhaps we can exchange ideas? -- "Nudist welfare man's wife fell for Chinese hypnotist >from the Co-Op bacon counter" - News of the World headline Ian Johnson Internet: ijj@inf.rl.ac.uk CLRC Rutherford Appleton Laboratory, World-Wide Web: Chilton, Didcot, Oxon OX11 0QX. http://www.cis.rl.ac.uk/people/ijj.html From rem-conf-request@es.net Thu Nov 21 10:36:18 1996 Received: from max3.rrze.uni-erlangen.de by osi-east.es.net with ESnet SMTP (PP); Thu, 21 Nov 1996 07:35:42 -0800 Return-Path: Received: from opus.rrze.uni-erlangen.de by max3.rrze.uni-erlangen.de; Thu, 21 Nov 96 16:31:47 +0100 Received: from local by opus (SMI-8.6/cl-RRZE) id PAA11266; Thu, 21 Nov 1996 15:31:47 GMT Date: Thu, 21 Nov 1996 15:31:47 GMT From: Edgar Hellfritsch To: rem-conf@es.net Subject: audio: how to mike and headphone X-Sun-Charset: US-ASCII Message-Id: <329475e32650002@max3.rrze.uni-erlangen.de> hi verbing weirds language... another thing: we're doing 10-site videoconferences. one of our problems is recording and playing out audio. this would not be any problem if the partakers were technical personnel but we have to work with management material. there are several sets of equipment which all have their disadvantages. what we've tried out so far are: 1. echo cancellation (coherent callport): works fine only if participants don't interrupt one another. otherwise you get syllable salad. leaning forward and backward while talking isn't so good for the record level, either. 2. headset (sennheiser hme 25-1): excellent audio quality, but after half an hour your ears fall off from weight and pressure, and, you can't hear anything that's going on around you (phone, knocking, fire alarms, people going 'boo' at you...). also, everyone has a black rod sticking in their face all the time what doesn't make the video part of the meeting feel more natural. 3. the little 2-inch-mike'n'earclip-thingummies which come with intel proshare: they don't really isolate 'in' from 'out' acoustically, so your partners get echoes of themselves. better than the simple speaker/mike-combination, but still annoying. - except for people who love hearing themselves talk. 4. any microphone plus walkman earplugs: works excellently, until the first participant coughs, sneezes or generally raises his voice. then, because the sound is pressed directly into the auditory passage, your ears fall off. And, with separate in/out you've got a bundle of cables to handle (which can be solved by a little handiwork, sure, but i still have a dream of an elegant solution). 5. we have ordered single-ear headsets and sleeve-clip microphones, but we haven't found good products yet. So, who can give me advice how to handle audio without - echoes - microphone arms in your face - having to keep a fixed distance to some gadget - your ears falling off? Gratefully, Edgar Hellfritsch ___________________________________________________________________\,_____ Friedrich-Alexander-Universitaet Edgar Hellfritsch '` Regionales Rechenzentrum Erlangen Tel. +49.9131.858735, Fax .302941 Martensstr. 1 hellfritsch@rrze.uni-erlangen.de 91058 Erlangen, Germany http://www.uni-erlangen.de/~unrz47/ From rem-conf-request@es.net Thu Nov 21 11:23:57 1996 Received: from itd.nrl.navy.mil by osi-east.es.net with ESnet SMTP (PP); Thu, 21 Nov 1996 08:23:23 -0800 Received: from [132.250.92.68] (gumbo.itd.nrl.navy.mil) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA24068; Thu, 21 Nov 96 11:22:36 EST Message-Id: <9611211622.AA24068@itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 1996 11:22:52 -0400 To: ijj@inf.rl.ac.uk (Ian Johnson), rem-conf@es.net From: macker@itd.nrl.navy.mil (Joseph P. Macker) Subject: Re: Q: Visualisation over the MBone? (was Re: IMM 3.5a1 Alpha Release and Test) Cc: macker@itd.nrl.navy.mil At 3:07 PM 11/21/96 +0000, Ian Johnson wrote: >Joseph, >Your comments on some of the other uses you are hoping that MDP might >be suited for prompt me to ask the list: does anyone have experience of >distributing visualisations using reliable multicast? > I have always wondered if apps like jive did anything along these lines. I assume not much at present. > >What we're trying to acheive is a way of running a visualisation package >(currently AVS, but Iris Explorer is another candidate) between machines. >One approach we're trying is to intercept an AVS pipeline at the geometry >output stage and send this data to "slave" pipelines on other machines >which would then render the geometry. > I believe frameworks like MDP have a role to play in reliable multicasting, but so do frameworks like SRM (wb) and other approaches coming out of the distributed simulation community (dynamic consistency protocols)..I have another project along the real-time simulation line (state-based reliability paradigm). The proper answer depends upon what your application and scalability requirements are. Do you care about group ordering? Can you live with loose consistency? Do you need interactive response? > >We believe that the geometry output will small in size (a few KB at most). >We are looking for reliability (natch) - we can't afford to lose >geometry output! > For example, in explorer you could call WriteGeom to a file for reliable multicasting by MDP and have and an explorer post processor on the other end do a ReadGeom upon reception. MDP could be easily configured to reliable disseminate the geometry structures, but CAUTION this may not be the protocol framework you want to use depending on your requirements. MDP is best suited to scalable multicast file transfer within a group (while trying to being nice to the network) and its not designed to support interactiveness extremely well. SRM-like approaches are better for interactive applications. The visualization application sounds real interesting..For something simple, I'd like to try a VRML post processor client with the latest IMM distribution. -joe From rem-conf-request@es.net Thu Nov 21 14:11:40 1996 Received: from bmrc.Berkeley.EDU by osi-east.es.net with ESnet SMTP (PP); Thu, 21 Nov 1996 11:10:54 -0800 Received: from nobozo.CS.Berkeley.EDU (nobozo.CS.Berkeley.EDU [128.32.34.58]) by bmrc.Berkeley.EDU (8.8.2/8.6.9) with SMTP id LAA27387 for <298-list@bmrc.Berkeley.EDU>; Thu, 21 Nov 1996 11:04:50 -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 LAA23761 for <298-list@bmrc>; Thu, 21 Nov 1996 11:04:52 -0800 Date: Thu, 21 Nov 1996 11:04:52 -0800 Message-Id: <199611211904.LAA23761@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 From: Jerrlyn Iwata Subject: Berkeley Multimedia & Graphics Seminar Berkeley Multimedia and Graphics Seminar (Wednesday November 27, 1996 12:30-2:00 PDT 405 Soda Hall) "Quality of Service and Asynchronous Transfer Mode in IP Internetworks" Bruce A. Mah U.C. Berkeley The deployment of Asynchronous Transfer Mode (ATM) networks is a recent development in the field of computer communication. When we attempt to use these networks as a part of the existing Internet we see a large gap between the data forwarding models of ATM (virtual circuits supporting performance guarantees) and IP (datagrams, usually best-effort). In our research, we have examined some different policies for IP-over-ATM networks to try to use the strengths of IP and ATM to try to bridge this gap. We have examined different quality of service, multiplexing, and virtual circuit management policies, and evaluated their relative merits from the standpoint of the performance of typical Internet applications. Our evaluation uses a simulation of a large IP internetwork and network traffic as sent by common Internet applications. The results show that the use of different scheduling algorithms and QOS parameters can be used to express preference for (or to restrict) certain applications. We see that multiplexing can improve application performance due to a reduced need to set up ATM virtual circuits, although interactions with some network service disciplines can negate these effects. Finally, we show that caching idle virtual circuits for reuse is, in general, beneficial for both network and application performance. ------------------------------------------------------------------------------ This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40 PDT (GMT - 8 hrs). See sd or http://bmrc.berkeley.edu/298 for instructions on setting up, connecting to, and operating the MBONE tools. Please direct technical questions to davesimp@cs.berkeley.edu From rem-conf-request@es.net Thu Nov 21 14:16:25 1996 Received: from msri.msri.org (actually msri.org) by osi-east.es.net with ESnet SMTP (PP); Thu, 21 Nov 1996 11:15:39 -0800 Received: (from smap@localhost) by msri.msri.org (8.8.2/8.7.2) id LAA07385 for ; Thu, 21 Nov 1996 11:15: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 sma007379; Thu Nov 21 11:15:39 1996 Received: by hille.msri.org (8.7/MSRI) id LAA15295; Thu, 21 Nov 1996 11:25:12 -0800 (PST) Date: Thu, 21 Nov 1996 11:25:12 -0800 (PST) Message-Id: <199611211925.LAA15295@hille.msri.org> From: neal Reply-to: neal@msri.org Subject: MacMahon's Partition Analysis and Computer Algebra MBone Broadcast Announcement ---------------------------- Title: MacMahon's Partition Analysis and Computer Algebra Date: Nov 25, 1996 Time: 16:15 PST8PDT 1 hours Contact: neal@msri.org URL: http://www.msri.org/lecturenotes/96/epos/andrews/ Description: At the turn of the century, P.A. MacMahon developed a linear operator method to treat numerous problems in partitions. He called his method Partition Analysis. He designed it to solve problems in plane partitions, and in his book, Combinatory Analysis, he acknowledges that he failed to complete the project. As a result his methods were almost completely neglected. The only subsequent major use of the method was by Richard Stanley in the early 1970's when he proved the Anand-Dumir-Gupta Conjecture. The object of this talk will be a discussion of why the advent of computer algebra suggests that reconsideration of MacMahon's original project is merited. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Thu Nov 21 16:00:37 1996 Received: from hplms26.hpl.hp.com by osi-east.es.net with ESnet SMTP (PP); Thu, 21 Nov 1996 12:59:33 -0800 Received: from hplabsz.hpl.hp.com by hplms26.hpl.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3+HPL1.1S) id AA188669966; Thu, 21 Nov 1996 12:59:27 -0800 Received: by hplabsz.hpl.hp.com (1.37.109.20/15.5+ECS 3.3+HPL1.1) id AA166599968; Thu, 21 Nov 1996 12:59:28 -0800 From: deleon@hplabsz.hpl.hp.com (Laura de Leon ) Message-Id: <9611211259.ZM16657@hplabsz.hpl.hp.com> Date: Thu, 21 Nov 1996 12:59:28 -0800 X-Mailer: Z-Mail (3.0.0 15dec93) To: baylisa@baylisa.org, sage-members@usenix.org, rem-conf@es.net Subject: TONIGHT BayLISA: Randal Schwartz, Just Another Convicted Perl Hacker Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 The BayLISA group meets monthly to discuss topics of interest to systems and network administrators. The meetings are free and open to the public. BayLISA holds monthly meetings on the third Thursday of each month at 7:30 PM PST. We meet at Cisco building J in San Jose, on Tasman Drive near First street. (This is across the street from the room we met in at Cisco last month). See www.baylisa.org for more information. The meetings are also broadcast via MBONE. NOTE: AS OF OCTOBER, WE HAVE MOVED TO CISCO. This is a new location. Thanks very much to Synopsys for hosting us. Schedule -------- November 21 Randal Schwartz: Just Another Convicted Perl Hacker This talk will describe how the speaker became a felon in the process of doing his job as a systems administrator in the well-publicized Oregon v. Schwartz case (victim: Intel). It will include some points about Oregon's current law and the implications of this case on the computer community. There will be a special focus on how to make sure this doesn't happen to you. There will be copies of Randal's new PERL book available if you would like to get one signed. BayLISA Board Elections & member meeting before the regular meeting At 7:00, Elections for the BayLISA board will be held. We encourage all members to vote. If you aren't a member, this is a good time to join (see our Web site) December 19 Our Holiday meeting-- Join us to share goodies and computer horror stories, as well as descriptions of stupid computer tricks. There will be a prize for best story. This is a very informal meeting, and will not be broadcast on the MBONE. January 16 Brent Chapman, Containment Zones (firewalls to keep people in) February 20 Standards efforts and how they will effect you March 20 Paul Vixie [Schedule subject to change] For further information on BayLISA, check out our web site: http://www.baylisa.org/ To get further information on the meeting location, you can also ftp it from ftp.baylisa.org:/location For any other information, please send email to: info@baylisa.org If you have any questions, please contact me or the info alias listed above. From rem-conf-request@es.net Thu Nov 21 16:13:11 1996 Received: from basil.cdt.luth.se by osi-east.es.net with ESnet SMTP (PP); Thu, 21 Nov 1996 13:12:05 -0800 Received: from demo.cdt.luth.se (root@demo.cdt.luth.se [130.240.64.66]) by basil.cdt.luth.se (8.7.5/8.7.3) with ESMTP id WAA16786; Thu, 21 Nov 1996 22:09:12 +0100 (MET) Received: from demo (peppar@localhost [127.0.0.1]) by demo.cdt.luth.se (8.6.12/8.6.12) with ESMTP id WAA29380; Thu, 21 Nov 1996 22:11:50 +0100 Message-Id: <199611212111.WAA29380@demo.cdt.luth.se> To: rem-conf@es.net, lsma@gmu.edu, ietf-dis@gmu.edu Subject: I-D ACTION:draft-parnes-rtp-ext-srm-01.txt MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Date: Thu, 21 Nov 1996 22:11:50 +0100 From: Peter Parnes ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Hi I'd appreciate any negative or positive comments on my draft regarding how to extend RTP to include some of the ideas of the SRM-framework. /P ------- =_aaaaaaaaaa0 Content-Type: multipart/digest; boundary="----- =_aaaaaaaaaa1" ------- =_aaaaaaaaaa1 >From ietf-announce-request@ietf.org Thu Nov 21 21:16:59 1996 Received: from ietf.org (ietf.org [132.151.1.19]) by basil.cdt.luth.se (8.7.5/8.7.3) with SMTP id VAA15784; Thu, 21 Nov 1996 21:16:56 +0100 (MET) Received: from ietf.org by ietf.org id aa07363; 21 Nov 96 9:57 EST Received: from ietf.org by ietf.org id aa04300; 21 Nov 96 9:40 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Sender: ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-parnes-rtp-ext-srm-01.txt Date: Thu, 21 Nov 1996 09:40:12 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611210940.aa04300@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTP extension for Scalable Reliable Multicast Author(s) : P. Parnes Filename : draft-parnes-rtp-ext-srm-01.txt Pages : 15 Date : 11/21/1996 This document describes how the Real-time Transport Protocol, RTP (RFC1889), could be extended to include support for parts of the framework called Scalable Reliable Multicast. The scheme proposed could be used for transporting a data flow reliably over the transport protocols supported by RTP in a light-weight way. This could be used for numerous applications, for instance white-boards, semi-reliable audio/video and messaging/data-transfers within group-ware applications. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-parnes-rtp-ext-srm-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-parnes-rtp-ext-srm-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-parnes-rtp-ext-srm-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121092229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-parnes-rtp-ext-srm-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-parnes-rtp-ext-srm-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121092229.I-D@ietf.org> --OtherAccess-- --NextPart-- ------- =_aaaaaaaaaa1-- ------- =_aaaaaaaaaa0-- From rem-conf-request@es.net Thu Nov 21 16:54:00 1996 Received: from mach-1.tridis.ist.ucf.edu (actually Mach-1.ist.ucf.edu) by osi-east.es.net with ESnet SMTP (PP); Thu, 21 Nov 1996 13:52:41 -0800 Received: by mach-1.tridis.ist.ucf.edu (SMI-8.6/SMI-SVR4) id QAA25087; Thu, 21 Nov 1996 16:52:23 -0500 Date: Thu, 21 Nov 1996 16:52:23 -0500 Message-Id: <199611212152.QAA25087@mach-1.tridis.ist.ucf.edu> From: Myjak To: ijj@inf.rl.ac.uk, macker@itd.nrl.navy.mil cc: rem-conf@es.net, lsma@gmu.edu Subject: Re: Q: Visualisation over the MBone? Ian, Joseph, Interesting subject! At 3:07 PM 11/21/96 +0000, Ian Johnson wrote: >Joseph, >Your comments on some of the other uses you are hoping that MDP might >be suited for prompt me to ask the list: does anyone have experience of >distributing visualisations using reliable multicast? If you consider distributed interactive simulation *and* dynamic terrain environments as distributed visualizations, then yes, we have. Also you might look into Global Cast communications Inc., they have a variety of experiences using RMP (their COTS solution). Also some recent research into HLA (www.dmso.mil/projects/HLA) looks like it will offer some interesting possibilities here as well. >What we're trying to acheive is a way of running a visualisation package >(currently AVS, but Iris Explorer is another candidate) between machines. >One approach we're trying is to intercept an AVS pipeline at the geometry >output stage and send this data to "slave" pipelines on other machines >which would then render the geometry. } Joseph Macker (macker@itd.nrl.navy.mil) wrote: } I believe frameworks like MDP have a role to play in reliable } multicasting, but so do frameworks like SRM (wb) and other } approaches coming out of the distributed simulation community } (dynamic consistency protocols). I have another project along } the real-time simulation line (state-based reliability paradigm). } The proper answer depends upon what your application and } scalability requirements are. } Do you care about group ordering? } Can you live with loose consistency? } Do you need interactive response? to which I'd add: Is fidelity important? and/or varying levels of detail? tightly or loosly coupled? what kind of update rate do you need to maintain? What kind of latency (communication, update, consistency, etc.) can you withstand? is jitter imporant (how much variance can you withstand)? In simulation world, we are also concerned when the envrionment is static or dynamic? We've noticed strengths and weaknesses when using either distributed (peer to peer) or centrally located (client/server) environments. In short... we're waiting on results of the SEDRIS project... SEDRIS/RMP? hmmm > We believe that the geometry output will [be] small in size (a few > KB at most). We are looking for reliability (natch) - we can't > afford to lose geometry output! > Its a function of the size of the environment, rate of change, number of interactions, performance, etc. Our experience has been that maintaining consistency across even a few (<=10) hosts generates a lot more then a few KB worth of data. YMMV. } [...] The visualization application sounds real interesting..For } something simple, I'd like to try a VRML post processor client with } the latest IMM distribution. - -joe I've been wondering (wandering?) about this too, perhaps some of the vrml folks on the LSMA list might be able to add something here. -- Net@You.Later, - Michael D. Myjak Senior Research Scientist Institute for Simulation and Training The University of Central Florida email: Voice: 407.658.5043 FAX: 407.658.5059 LAB: 407.658.5078 Off the keyboard, over the bridge, through the router... Nothin' but Net! From rem-conf-request@es.net Thu Nov 21 18:04:28 1996 Received: from itd.nrl.navy.mil by osi-east.es.net with ESnet SMTP (PP); Thu, 21 Nov 1996 15:02:54 -0800 Received: from [132.250.92.68] (gumbo.itd.nrl.navy.mil) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA13664; Thu, 21 Nov 96 18:02:26 EST Message-Id: <9611212302.AA13664@itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 1996 18:02:42 -0400 To: Myjak , ijj@inf.rl.ac.uk From: macker@itd.nrl.navy.mil (Joseph P. Macker) Subject: Re: Q: Visualisation over the MBone? Cc: rem-conf@es.net, lsma@gmu.edu At 4:52 PM 11/21/96 -0500, Myjak wrote: >Ian, Joseph, > >Interesting subject! > >........... > >In simulation world, we are also concerned when the envrionment is >static or dynamic? We've noticed strengths and weaknesses when using >either distributed (peer to peer) or centrally located (client/server) >environments. In short... we're waiting on results of the >SEDRIS project... SEDRIS/RMP? hmmm Mike: Good comments... Along the lines of RMP,etc. there are additional tradeoffs to be considered when looking at the "token ring" approaches such as RMP and ISIS for scaled up WAN applications that were not mentioned. Mainly delay and protocol efficiency. Of course strict ordering and "all that" is achievable if needed, but there are some penalties vs. tree-based approaches. FYI, I have an ongoing effort looking at an improved consistency protocol ported into a generic IP API (original work done by MIT/LADS) for distributed simulation applications that takes into account the changing dynamic state of simulation objects (steady state vs. dynamic) and potentially allows for migration of objects across multiple multicast groups within a larger simulation. The bandwidth savings can be highly significant when factoring in such application layer issues as object dynamics and prediction. Sorry I went off on a tangent, but its a very interesting topic area. It would be nice to have an MBone application that could test protocol causality effects in a low-moderate bandwidth application (e.g., a robot soccer (football) game might suffice ...) the MBone World Cup. Actually, a buddy and I started something like this here and have a basic version working, but its not finished. -joe From rem-conf-request@es.net Thu Nov 21 23:38:54 1996 Received: from N3.SP.CS.CMU.EDU by osi-east.es.net with ESnet SMTP (PP); Thu, 21 Nov 1996 20:38:18 -0800 Subject: MBone Session Directory on WWW To: rem-conf@es.net Date: Thu, 21 Nov 1996 23:38:05 -0500 (EST) From: Rex Xi Xu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 427 Hello everyone: Our experimental "MBone Session Directory" page is now almost ready: http://www.cs.cmu.edu/~rexx/mbone-sd.html Without running sd/sdr yourself, from this link you can find what's happening on MBone right now, and you can even start MBone tools >from there. Check it out for yourself! The page is still in testing. Any comments/suggestions are welcome. -- rex rexx@cs.cmu.edu http://www.cs.cmu.edu/~rexx/ From rem-conf-request@es.net Fri Nov 22 03:58:03 1996 Received: from basil.cdt.luth.se by osi-east.es.net with ESnet SMTP (PP); Fri, 22 Nov 1996 00:57:22 -0800 Received: from demo.cdt.luth.se (root@demo.cdt.luth.se [130.240.64.66]) by basil.cdt.luth.se (8.7.5/8.7.3) with ESMTP id JAA25615 for ; Fri, 22 Nov 1996 09:54:31 +0100 (MET) Received: from demo (peppar@localhost [127.0.0.1]) by demo.cdt.luth.se (8.6.12/8.6.12) with ESMTP id JAA11240 for ; Fri, 22 Nov 1996 09:57:09 +0100 Message-Id: <199611220857.JAA11240@demo.cdt.luth.se> To: rem-conf@es.net Subject: Re: MBone Session Directory on WWW In-reply-to: Your message of "Thu, 21 Nov 1996 23:38:05 EST." <199611220445.AA20879@goliat.dc.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Nov 1996 09:57:08 +0100 From: Peter Parnes And yet another MBone Session Directory on the WWW can be found at . This one is called the CDT Session Directory, CSD. There are alot of these now ;-) > Our experimental "MBone Session Directory" page is now almost ready: This goes for mine to :-) (The almost part :-) /P From rem-conf-request@es.net Fri Nov 22 10:06:56 1996 Received: from ist.ucf.edu (actually babylon.ist.ucf.edu) by osi-east.es.net with ESnet SMTP (PP); Fri, 22 Nov 1996 07:06:06 -0800 Received: from ist_smtp.ist.ucf.edu (ist_smtp.ist.ucf.edu [132.170.193.5]) by ist.ucf.edu (8.7.3/8.7.3) with SMTP id KAA21627; Fri, 22 Nov 1996 10:05:51 -0500 (EST) Received: by ist_smtp.ist.ucf.edu with Microsoft Mail id <3295C182@ist_smtp.ist.ucf.edu>; Fri, 22 Nov 96 10:06:42 EST From: "Myjak, Michael" To: ijj , macker , Myjak Cc: lsma , rem-conf Subject: RE: Q: Visualization over the MBone? Date: Fri, 22 Nov 96 10:05:00 EST Message-ID: <3295C182@ist_smtp.ist.ucf.edu> Encoding: 71 TEXT X-Mailer: Microsoft Mail V3.0 > Along the lines of RMP,etc. there are additional tradeoffs to be considered > when looking at the "token ring" approaches such as RMP and ISIS for scaled > up WAN applications that were not mentioned. Mainly delay and protocol > efficiency. Of course strict ordering and "all that" is achievable if > needed, but there are some penalties vs. tree-based approaches. I have looked into Global Cast Communications implementation of RMP (for LANs) and their statistically reliable multicast (SRM) protocol for WAN-based implementations. We currently have a contract proposal in the mill to investigate these implementations, perhaps in a simulated LAN/MAN/WAN environment. Since they use a best-effort strategy for delivery and ACK (or NAK) from a few selected hosts, I suspect that latency and (perhaps more importantly) jitter should be comparable to non-reliable IPmc implementations. Once we've set up the lab, it will be interesting to see how the number of groups vs. entities scale, how NBMA and in particular MARS affects latency and jitter, and at what we can join/resign from IPmc groups. > FYI, I have an ongoing effort looking at an improved consistency protocol > ported into a generic IP API (original work done by MIT/LADS) for > distributed simulation applications that takes into account the changing > dynamic state of simulation objects (steady state vs. dynamic) and > potentially allows for migration of objects across multiple multicast > groups within a larger simulation. The bandwidth savings can be highly > significant when factoring in such application layer issues as object > dynamics and prediction. Sorry I went off on a tangent, but its a very > interesting topic area. Is this related to or build off of the work done by David Cebula, Stephen Kolek, and Dan Van Hook of MIT Lincoln Labs? They did some of the performance analysis work on the STOW ED1A experiment and presented several (most excellent)papers at the 14th DIS workshop last spring. Part of their work investigated the use of a consistency protocol in that environment. Given that HLA provides a mechanism to manage/rehost objects, the idea of factoring in application issues (such as object dynamics and prediction) indeed can produce a significant savings in bandwidth reduction, host CPU optimization, and the like, yielding even larger simulations. Unfortunately, my ASTT white paper on this wasn't accepted. I guess DARPA has more important priorities right now then federation efficiency. > It would be nice to have an MBone application that could test protocol > causality effects in a low-moderate bandwidth application (e.g., a robot > soccer (football) game might suffice ...) the MBone World Cup. Actually, a > buddy and I started something like this here and have a basic version > working, but its not finished. I like this idea. I have a set of students that come into the lab on Friday nights (we call them Toy Scouts) and they would probably just at the chance to help craft this. Lets talk ... all the best - -- Michael Myjak Senior Research Scientist Institute for Simulation and Training University of Central Florida * 3280 Progress Drive * Orlando, Florida 32826 email: myjak@ist.ucf.edu * voice: 407.658.5043 * FAX: 407.658.5059 Off the keyboard, over the bridge, through the router... nothing but 'net! From rem-conf-request@es.net Fri Nov 22 13:23:26 1996 Received: from mail4.microsoft.com by osi-east.es.net with ESnet SMTP (PP); Fri, 22 Nov 1996 10:22:39 -0800 Received: by mail4.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BBD85F.3F6E3320@mail4.microsoft.com>; Fri, 22 Nov 1996 10:23:48 -0800 Message-ID: From: Stefan Solomon To: "'rem-conf@es.net'" , 'Rex Xi Xu' Subject: RE: MBone Session Directory on WWW Date: Fri, 22 Nov 1996 10:22:34 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 27 TEXT Check also this: http://archive.thepoint.net/Win32SD/README.html. This is a SAP client API similar to what we are doing. >---------- >From: Rex Xi Xu[SMTP:rexx@N3.SP.CS.CMU.EDU] >Sent: Thursday, November 21, 1996 8:38 PM >To: rem-conf@es.net >Subject: MBone Session Directory on WWW > > >Hello everyone: > >Our experimental "MBone Session Directory" page is now almost ready: > >http://www.cs.cmu.edu/~rexx/mbone-sd.html > >Without running sd/sdr yourself, from this link you can find what's >happening on MBone right now, and you can even start MBone tools >from there. Check it out for yourself! > >The page is still in testing. Any comments/suggestions are welcome. > >-- >rex >rexx@cs.cmu.edu >http://www.cs.cmu.edu/~rexx/ > From rem-conf-request@es.net Fri Nov 22 13:49:26 1996 Received: from itd.nrl.navy.mil by osi-east.es.net with ESnet SMTP (PP); Fri, 22 Nov 1996 10:48:42 -0800 Received: from [132.250.92.68] (gumbo.itd.nrl.navy.mil) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA13352; Fri, 22 Nov 96 13:48:05 EST Message-Id: <9611221848.AA13352@itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Nov 1996 13:48:22 -0400 To: "Myjak, Michael" , ijj , Myjak From: macker@itd.nrl.navy.mil (Joseph P. Macker) Subject: RE: Q: Visualization over the MBone? Cc: lsma , rem-conf At 10:05 AM 11/22/96 -0500, Myjak, Michael wrote: >I have looked into Global Cast Communications implementation of RMP (for >LANs) and their statistically reliable multicast (SRM) protocol for >WAN-based implementations. We currently have a contract proposal in the For clarity, when I referenced SRM, I meant (the Scalable Reliable Multicast (SRM) framework) developed for wb at lbl..I don't know what statistically reliable multicast is. > >Is this related to or build off of the work done by David Cebula, Stephen >Kolek, and Dan Van Hook of MIT Lincoln Labs? They did some of the >performance analysis work on the STOW ED1A experiment and presented >several (most excellent)papers at the 14th DIS workshop last spring. Part >of their work investigated the use of a consistency protocol in that >environment. Yes, Josh Smith/DV Hook's original work is the basis for this and we. LADS has done some initial work porting this to a generic IP set of libraries. I have helped get a more flexible set of functionality support into the protocol. We are just starting to look at the latest release (debugging, check-out phase). Should be interesting. later, -joe From rem-conf-request@es.net Fri Nov 22 16:50:45 1996 Received: from INET-01-IMC.microsoft.com (actually mail1.microsoft.com) by osi-east.es.net with ESnet SMTP (PP); Fri, 22 Nov 1996 13:49:09 -0800 Received: by INET-01-IMC.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BBD87B.EEE4CE10@INET-01-IMC.microsoft.com>; Fri, 22 Nov 1996 13:49:08 -0800 Message-ID: From: Stefan Solomon To: 'Arlie Davis' , "'rem-conf@es.net'" Subject: RE: MBone Session Directory on WWW Date: Fri, 22 Nov 1996 13:49:03 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 16 TEXT Sorry, this mail should be ignored. This is out of context and was not intended to be sent to this audience. Stefan > >>-----Original Message----- >>From: Stefan Solomon [SMTP:stefans@MICROSOFT.com] >>Sent: Friday, November 22, 1996 1:23 PM >>To: 'rem-conf@es.net'; 'Rex Xi Xu' >>Subject: RE: MBone Session Directory on WWW >> >>Check also this: http://archive.thepoint.net/Win32SD/README.html. This >>is a SAP client API similar to what we are doing. >> > From rem-conf-request@es.net Fri Nov 22 17:14:29 1996 Received: from mercury.lcs.mit.edu by osi-east.es.net with ESnet SMTP (PP); Fri, 22 Nov 1996 14:13:54 -0800 Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id RAA05695 for rem-conf@es.net; Fri, 22 Nov 1996 17:13:53 -0500 X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: rem-conf@es.net Subject: Re: MBone Session Directory on WWW In-reply-to: Your message of "Fri, 22 Nov 96 10:22:34 PST." Date: Fri, 22 Nov 96 17:13:53 -0500 Message-ID: <5492.848700833@mercury.lcs.mit.edu> Sender: mjh@mercury.lcs.mit.edu X-Mts: smtp Just a quick comment on use of the Web for session directories... One of the big advantages of the original sd model (now SAP) is that you can only receive the description if you are within the scope of the session. This is definitely a good idea from the users point of view. I have sdr-server code (part finished - the server is primarily a cache) that implements a web interface, but the model was that you really wanted to run one server per site, and connect to your local server because that way you discover your local sessions not someone else's local sessions. Mark From rem-conf-request@es.net Fri Nov 22 17:46:45 1996 Received: from ist.ucf.edu (actually babylon.ist.ucf.edu) by osi-east.es.net with ESnet SMTP (PP); Fri, 22 Nov 1996 14:45:47 -0800 Received: from ist_smtp.ist.ucf.edu (ist_smtp.ist.ucf.edu [132.170.193.5]) by ist.ucf.edu (8.7.3/8.7.3) with SMTP id RAA26252; Fri, 22 Nov 1996 17:45:44 -0500 (EST) Received: by ist_smtp.ist.ucf.edu with Microsoft Mail id <32962D56@ist_smtp.ist.ucf.edu>; Fri, 22 Nov 96 17:46:46 EST From: "Myjak, Michael" To: ijj , macker Cc: lsma , "Myjak, Michael" , rem-conf Subject: RE: Q: Visualization over the MBone? Date: Fri, 22 Nov 96 17:45:00 EST Message-ID: <32962D56@ist_smtp.ist.ucf.edu> Encoding: 24 TEXT X-Mailer: Microsoft Mail V3.0 > > For clarity, when I referenced SRM, I meant (the Scalable > Reliable Multicast (SRM) framework) developed for wb at lbl. > .I don't know what statistically reliable multicast is. Yes, your correct, the official name is Scaleable. But in reality, it provides at best, a statistical reliability. (I should quit calling it statistical reliable multicast...) If I understand it correctly, SRM guarantees delivery not to the application; but to the LIS. One machine on the LIS then ack's (or NACs) for all. > Yes, Josh Smith/DV Hook's original work is the basis for this and we. LADS > has done some initial work porting this to a generic IP set of libraries. > I have helped get a more flexible set of functionality support into the > protocol. We are just starting to look at the latest release (debugging, > check-out phase). Should be interesting. Very. Keep us informed! Michael From rem-conf-request@es.net Sat Nov 23 03:02:39 1996 Received: from proxy1.ba.best.com by osi-east.es.net with ESnet SMTP (PP); Sat, 23 Nov 1996 00:01:11 -0800 Received: from mg134-121.ricochet.net (mg134-121.ricochet.net [204.179.134.121]) by proxy1.ba.best.com (8.8.3/8.8.3) with SMTP id XAA19738 for ; Fri, 22 Nov 1996 23:59:11 -0800 (PST) Date: Fri, 22 Nov 1996 23:59:11 -0800 (PST) Message-Id: <1.5.4.16.19961123004957.860f0bb8@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: rem-conf@es.net From: Ross Finlayson Subject: Re: RTCP RR's A few (somewhat belated) thoughts on this issue: It seems unlikely that we can come up with a single "one size fits all" algorithm for when/how often to send RRs. There's a clear tradeoff between the desired RR bandwidth seen by each node and the frequency at which nodes can report, and the currently specified algorithm doesn't scale well as the number of nodes (N) increases. (The per node report rate decreases as 1/N, and each node's reports might eventually become too infrequent to be useful.) It also seems that in some situations - e.g., a single sender multicasting to many recipients that are on low-bandwidth leaves (or maybe just have low-bandwidth uplinks) - we may not need RRs at all. These senders will probably just go ahead and send based on whatever bandwidth they've already chosen as a baseline (e.g., 14.4 or 28.8 kbps), with no intention of adjusting this based on feedback from recipients. (As others have noted, it's essential that RTP/RTCP be useable in low-bandwidth environments, otherwise we'll forever be forced to live with nonstandard hacks for this case.) I also think that the our current architectural philosophy of "keeping the intelligence in the leaves" is one that we should try to preserve as much as possible. Once we start down the path of *requiring* translators/aggregators/mixers/proxies etc. inside the network, we end up with an architecture that becomes much harder to implement and deploy. Unicast-based feedback schemes are another possibility. They raise obvious performance/scaling issues, of course, but they may work well in some situations - e.g., in sender-rooted tree-based topologies where the available bandwidth increases (proportional to the branching factor) as you move up the tree. (Perhaps some of the cable-based systems will have topologies that are sufficiently well-contrstrained to make this possible?) Fortunately though, even if we stick to multicast-based approaches (using a single multicast group), there is another parameter that end-nodes can adjust: the TTL scope of outgoing packets. This could lead to more scalable algorithms for RRs. As the number of nodes increases, you could maintain a useful per-node report rate by reducing the TTL. Of course, the drawback here is that the nodes most interested in receiving RRs would no longer receive all of them. However, I can imagine schemes in which nodes would occasionally send high-TTL reports that contain summaries of recently-received low-TTL 'raw' reports. Another possibility is to use more than one multicast group (with not all nodes being members of each such group). I guess the bottom line is that until we know which schemes will work best, we should make sure that there are sufficient hooks in place to allow continued experimentation. Ross. From rem-conf-request@es.net Sat Nov 23 12:59:07 1996 Received: from hofmann.CS.Berkeley.EDU by osi-east.es.net with ESnet SMTP (PP); Sat, 23 Nov 1996 09:58:32 -0800 Received: from internaut.com (Cust108.Max16.Seattle.WA.MS.UU.NET [153.34.42.236]) by hofmann.CS.Berkeley.EDU (8.6.11/8.6.6.Beta11) with SMTP id JAA23835; Sat, 23 Nov 1996 09:58:24 -0800 Received: from [204.57.137.9] by internaut.com (NX5.67c/NeXT-3.0) id AA11238; Sat, 23 Nov 96 09:52:24 -0800 Received: by multi with Microsoft Mail id <01BBD924.89162300@multi>; Sat, 23 Nov 1996 09:56:02 -0800 Message-Id: <01BBD924.89162300@multi> From: Bernard Aboba To: "rem-conf@es.net" , 'Ross Finlayson' Subject: RE: RTCP RR's Date: Sat, 23 Nov 1996 09:56:01 -0800 Encoding: 40 TEXT Ross Finlayson said: >Fortunately though, even if we stick to multicast-based approaches (using a >single multicast group), there is another parameter that end-nodes can >adjust: the TTL scope of outgoing packets. This could lead to more scalable >algorithms for RRs. As the number of nodes increases, you could maintain a >useful per-node report rate by reducing the TTL. Of course, the drawback >here is that the nodes most interested in receiving RRs would no longer >receive all of them. However, I can imagine schemes in which nodes would >occasionally send high-TTL reports that contain summaries of >recently-received low-TTL 'raw' reports. How is use of summary records/TTL different from the RTP translator/proxy approach? >Another possibility is to use more than one multicast group (with not all >nodes being members of each such group). For example, different groups could be used for sender and receiver reports. The receivers would only send to the receiver report group but would not join it. Both senders and receivers would join the sender report group. >I guess the bottom line is that until we know which schemes will work best, >we should make sure that there are sufficient hooks in place to allow >continued experimentation. Well, it's hard to know which schemes will work best if we don't even have agreement on what we mean by "best." I would propose that the following metrics be used to judge how well a scheme performs: Decrease in RTCP bandwidth usage Decrease in effective RTCP sending population Quality of receiver reporting information . From rem-conf-request@es.net Sat Nov 23 16:46:20 1996 Received: from proxy1.ba.best.com by osi-east.es.net with ESnet SMTP (PP); Sat, 23 Nov 1996 13:45:37 -0800 Received: from mg131-050.ricochet.net (mg131-050.ricochet.net [204.179.131.50]) by proxy1.ba.best.com (8.8.3/8.8.3) with SMTP id NAA07015; Sat, 23 Nov 1996 13:42:43 -0800 (PST) Date: Sat, 23 Nov 1996 13:42:43 -0800 (PST) Message-Id: <1.5.4.16.19961123143320.0bffd046@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: Bernard Aboba From: Ross Finlayson Subject: RE: RTCP RR's Cc: "rem-conf@es.net" >>Fortunately though, even if we stick to multicast-based approaches (using a >>single multicast group), there is another parameter that end-nodes can >>adjust: the TTL scope of outgoing packets. This could lead to more scalable >>algorithms for RRs. As the number of nodes increases, you could maintain a >>useful per-node report rate by reducing the TTL. Of course, the drawback >>here is that the nodes most interested in receiving RRs would no longer >>receive all of them. However, I can imagine schemes in which nodes would >>occasionally send high-TTL reports that contain summaries of >>recently-received low-TTL 'raw' reports. > >How is use of summary records/TTL different from the RTP translator/proxy approach? Because it would still be only the leaves that send out the reports (both 'raw' (low-TTL, more frequent) and 'summaries' (higher-TTL, less frequent)). I was still working from the assumption that no extra intelligence would be required within the network itself. >Well, it's hard to know which schemes will work best if we don't even have agreement >on what we mean by "best." I would propose that the following metrics be used to >judge how well a scheme performs: > >Decrease in RTCP bandwidth usage >Decrease in effective RTCP sending population >Quality of receiver reporting information Yes, good point. Ross. From rem-conf-request@es.net Sat Nov 23 17:31:42 1996 Received: from realtime.cc.missouri.edu by osi-east.es.net with ESnet SMTP (PP); Sat, 23 Nov 1996 14:30:50 -0800 Received: from localhost (ccshag@localhost) by realtime.cc.missouri.edu (8.7.4/8.7.1) with SMTP id QAA03588 for ; Sat, 23 Nov 1996 16:30:48 -0600 (CST) X-Authentication-Warning: realtime.cc.missouri.edu: ccshag owned process doing -bs Date: Sat, 23 Nov 1996 16:30:47 -0600 (CST) From: Paul 'Shag' Walmsley Sender: ccshag@cclabs.missouri.edu To: rem-conf@es.net Subject: Six hours of electronic music from KCOU - Columbia MO Message-ID: X-Disclaimer: The opinions of this writer do not necessarily represent those of the University of Missouri-Columbia. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII >From 4PM to 10PM CDT today (2200 GMT to 0400 GMT), we'll be multicasting two electronic music shows from KCOU, the student radio station of the University of Missouri-Columbia: Transient Underworld - an ambient/triphop/jungle electronic music expedition - hosted by DJ Phase - with guest DJ Anji - from 2200 GMT to 0100 GMT Curtis' Bass Station - an acid house/jazz/trance radio show - hosted by Curtis Stewart - from 0100 GMT to 0400 GMT The session is registered in sdr as "MBONE Electronic Music" and is being broadcasted via vat 4.0a9 in 20ms PCM. For those of you without sdr, the multicast group address is 224.2.150.233, port 18762. Multicast feedback is welcomed at . You can reach the DJs at (573) 882-8262. - Paul "Shag" Walmsley "Knowing is not enough." -- Hal Hartley, "Surviving Desire" From rem-conf-request@es.net Sat Nov 23 18:04:17 1996 Received: from proxy1.ba.best.com by osi-east.es.net with ESnet SMTP (PP); Sat, 23 Nov 1996 15:03:27 -0800 Received: from mg131-050.ricochet.net (mg131-050.ricochet.net [204.179.131.50]) by proxy1.ba.best.com (8.8.3/8.8.3) with SMTP id PAA02788 for ; Sat, 23 Nov 1996 15:00:46 -0800 (PST) Date: Sat, 23 Nov 1996 15:00:46 -0800 (PST) Message-Id: <1.5.4.16.19961123155123.09ff5af4@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: rem-conf@es.net From: Ross Finlayson Subject: RE: RTCP RR's [Apologies to anyone who gets this twice. I'm not sure if it made it the first time. (I got back a complaint about "too much included text".)] >>Fortunately though, even if we stick to multicast-based approaches (using a >>single multicast group), there is another parameter that end-nodes can >>adjust: the TTL scope of outgoing packets. This could lead to more scalable >>algorithms for RRs. As the number of nodes increases, you could maintain a >>useful per-node report rate by reducing the TTL. Of course, the drawback >>here is that the nodes most interested in receiving RRs would no longer >>receive all of them. However, I can imagine schemes in which nodes would >>occasionally send high-TTL reports that contain summaries of >>recently-received low-TTL 'raw' reports. > >How is use of summary records/TTL different from the RTP translator/proxy approach? Because it would still be only the leaves that send out the reports (both 'raw' (low-TTL, more frequent) and 'summaries' (higher-TTL, less frequent)). I was still working from the assumption that no extra intelligence would be required within the network itself. >Well, it's hard to know which schemes will work best if we don't even have agreement >on what we mean by "best." I would propose that the following metrics be used to >judge how well a scheme performs: > >Decrease in RTCP bandwidth usage >Decrease in effective RTCP sending population >Quality of receiver reporting information Yes, good point. Ross. . . . . . . . . . . . . . . . . . . From rem-conf-request@es.net Sun Nov 24 02:32:18 1996 Received: from moon (actually moon.bjnet.edu.cn) by osi-east.es.net with ESnet SMTP (PP); Sat, 23 Nov 1996 23:31:43 -0800 Received: by moon (5.x/SMI-SVR4) id AA13299; Sun, 24 Nov 1996 15:31:41 +0800 Date: Sun, 24 Nov 1996 15:31:41 +0800 From: haitao@moon.bjnet.edu.cn (Zhang Haitao) Message-Id: <9611240731.AA13299@moon> Apparently-To: rem-conf@es.net hi, i am writing a reliable multicast file transfer framework using the SRM provided by "Floyd/Jacobson/McCanne/Liu/Zhang", and i have two ideas about SRM: 1. how to implement the calculations of host-to-host one-way delay. suppose host A sends session packet in t1(in Host A's clock,A-Clock), and the timestamp t1 is recoreded in session packet, then host B receives it in t2(B-Clock), it generates a echo packet that record host A's IP address , timestamp t1(A-Clock) , timestamp t2(B-clock) , and pastes the echo packet at the end of host B's session packet. then host B sends its session packet(echo packet included) at t3(B-Clock) and host A receives it at t4(A-Clock), A made its own echo packet then .in host A, it check the echo packet in session packet sent from B, finds its own IP-address and confirm it is a valid echo. then A got four timestamp: t1,t4(A-clock) and t2,t3 (B-Clock), so the one-way delay of A-to-B can be calculated as: d(A,B)=((t4-t1)-(t3-t2))/2 ; i dont know how it is acutally implemented in reliable wb, and hope to learn some details from the authors. 2. how to identify the occurence of packet loss: i am using a slot queue to identify the packet loss. in the connection establishment progress , the receivers get the file length and the total slot number, which means how many data frames should be sent, and marked the whole slot array as empty ( not filled) ,and in sender the slot array is marked with 0x01 as filled. when host receive data frame , it gets the sequence number and marked the correspondent slot as filled. then we use a poll_slot() program to check there is any empty slot in queue, that is, firstly, get the first slot markd with empty ,and then see if any slot is filled after that, if so , that means a packet loss occurs and a NACK is needed. in this way, we can handle the out-of-order packet, not just by the sequence gap. when the NACK comes, the host can check the correspondent slot status(filled or empty) to know whether it is capable of data repair. hope to hear some advices about them, Best Regards, ----------------------------------------------------------------------- Zhang haitao, Email:haitao@moon.bjnet.edu.cn Lab of Multimedia and Networking, http://koala.ee.tsinghua.edu.cn Dept. of Electronic Engineering, Tsinghu University, Beijing, P.R.China ----------------------------------------------------------------------- From rem-conf-request@es.net Sun Nov 24 17:06:49 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Sun, 24 Nov 1996 14:06:10 -0800 Received: from port4.precept.com by precept.com (5.x/SMI-4.1) id AA10613; Sun, 24 Nov 1996 14:05:32 -0800 Date: Sun, 24 Nov 1996 15:15:44 -0800 (PST) From: Stephen Casner To: Ross Finlayson Cc: rem-conf@es.net Subject: Re: RTCP RR's In-Reply-To: <1.5.4.16.19961123004957.860f0bb8@pop.best.com> Message-Id: X-X-Sender: casner@little-bear.precept.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > It seems unlikely that we can come up with a single "one size fits all" > algorithm for when/how often to send RRs. ... > I guess the bottom line is that until we know which schemes will work best, > we should make sure that there are sufficient hooks in place to allow > continued experimentation. Mark Handley suggested to me that we define additional RTP profiles to specify other RTCP behaviors. I think that is an excellent suggestion because the participants in a session need to know how to behave, and we will surely get into trouble if some of the schemes are mixed. The profile for the session is specified in SDP on the "m=" line; currently only the value "RTP/AVP" is defined. Other session description mechanisms should also provide a means to specify the profile. We could define "RTP/AVB" (for broadcast) to be a unicast RTCP scheme or some other variation that would be the result of the experimentation you propose. I would hope to avoid defining a plethora of profiles, so the discussion and consensus process is still important. Also, I would define the "AVB" profile to be equal to the "AVP" profile except for the RTCP behavior. That is, I would copy (by reference) the set of payload type assignments, existing and future. -- Steve From rem-conf-request@es.net Sun Nov 24 21:58:18 1996 Received: from gw.navio.com by osi-east.es.net with ESnet SMTP (PP); Sun, 24 Nov 1996 18:57:23 -0800 Received: (from proxy@localhost) by gw.navio.com (8.6.12/8.6.9) id SAA00161 for ; Sun, 24 Nov 1996 18:57:21 -0800 Received: from lulu.navio.com(204.182.38.230) by tvsoft.com via smap (V1.3) id sma000148; Sun Nov 24 18:56:58 1996 Message-Id: <3.0.32.19961124185541.006d021c@gw.navio.com> X-Sender: brianb@gw.navio.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 24 Nov 1996 18:55:41 -0800 To: rem-conf@es.net From: Brian Bulkowski Subject: Re: RTCP RR's Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 11:59 PM 11/22/96 -0800, you wrote: >It seems unlikely that we can come up with a single "one size fits all" >algorithm for when/how often to send RRs. Since I started this thread, let me make a couple of comments after hearing all the responses. My original comments pointed out two flaws in current RTP/RTCP which make it *unusable* in environments I'm considering. 1) RTP/RTCP is not scaleable to million-node sessions since an unacceptable memory burden is on the clients, and the environments I'm talking about are uninteresting with smaller networks. (When you're making $1 per household, a 10,000 node network is a yawner.) 2) Mixers/translators are an unacceptable means of scaling RTP/RTCP because of the infrastructure cost, unless major routing vendors add this capibility. 3) The fact that these networks are highly asymetric means that RTP/RTCP will not work as spec'd. 5% causes congestion failure. 4) RTCP doesn't add much value in these networks. The actions to be taken on receiving bad RTCP packets are not application actions, but network admin actions. Cable systems today have their own methods of doing network administration, amplifier retuning, and the like. It would seem that the intelligent response would be to allow the sender to request whether it wants RRs, and if so, how much (a base factor). I suggest this be folded into the protocol. Perhaps something like an RTCP session type (to mimic the RTP payload type, but for RTCP) would be in order? I can conceive of another way to do it is to have me define my own RTP payload type that specifies no RR packets. This seems a little silly to me, but not unheard of. I believe the H.245 payload spec says that no RTCP BYE packets will be used, which is in direct violation of the main RTP spec. This doesn't feel right to me, as the RTCP behaviour I want has nothing to do with the data I'm carrying, and everything to do with the kind of networks I'm running on. This seems to greatly confuse an RTP implementation (it would have to sniff the payload types and adjust, and be updated as new payload types are defined, yikes). And, yes, I'm prototyping my work now on a protocol of my own invention. I'd use RTP if I could... but I know it won't work. I'm designing my protocol and interface such that when RTP adds the features I need, I can slot it in. I've got no desire to invent another stupid transport protocol, but I have a desire to show a product that meets customer demand. A final point is regarding RTP header sizes, which I know have been discussed here before. Some networks I'm talking about are using 188 byte MPEG packets. (Often in Aloha or slotted-aloha uplinks, for you history buffs.) 14 bytes per packet is a lot. I can get the features I need in 3 to 5 bytes of header. I want compressed RTP headers, or minimalist RTP headers, or conditional headers, or something. Cheers, brianb From rem-conf-request@es.net Mon Nov 25 07:18:32 1996 Received: from acacia.sucs.soton.ac.uk by osi-east.es.net with ESnet SMTP (PP); Mon, 25 Nov 1996 04:16:54 -0800 Received: from apollo.sucs.soton.ac.uk (apollo.sucs.soton.ac.uk [152.78.128.224]) by acacia.sucs.soton.ac.uk (8.8.2/server) with SMTP id MAA28340 for ; Mon, 25 Nov 1996 12:15:50 GMT Date: Mon, 25 Nov 1996 12:14:18 GMT From: David Holter Subject: Mbone over Win95 To: rem-conf@es.net Message-ID: Priority: Normal MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi, With reference to video capture cards for Mbone on Win95 has anyone has tested the system with the PictureTel 200P system? David Holter Networking Group Computing Services University of Southampton UK +44 1703 593571 +44 1703 593939 D.A.Holter@soton.ac.uk From rem-conf-request@es.net Mon Nov 25 16:39:10 1996 Received: from mailhost.Ipsilon.COM by osi-east.es.net with ESnet SMTP (PP); Mon, 25 Nov 1996 13:38:23 -0800 Received: from red.ipsilon.com (red.Ipsilon.COM [205.226.1.58]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id NAA26572; Mon, 25 Nov 1996 13:38:22 -0800 Received: from red.ipsilon.com by red.ipsilon.com (8.6.12) id NAA00904; Mon, 25 Nov 1996 13:39:19 -0800 Message-Id: <199611252139.NAA00904@red.ipsilon.com> X-Mailer: exmh version 1.6.4 10/10/95 To: Brian Bulkowski cc: rem-conf@es.net Subject: Re: RTCP RR's In-reply-to: Your message of "Sun, 24 Nov 1996 18:55:41 PST." <3.0.32.19961124185541.006d021c@gw.navio.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Nov 1996 13:39:19 -0800 From: Greg Minshall Brian, et al, One thing that shouldn't get lost in this discussion is the use of RTCP for understanding the current "state" of the network. This is useful for debugging, as well as for engineering. A proposal that said "if there are one speaker and n**n receivers, receivers shouldn't use RTCP to provide reception information" would cause us to lose this information. Similarly, the fact that RTCP is *multicast* is useful for this diagnosis/monitoring point of view. I'd be careful of proposals that eliminated the ability to monitor the network (though i certainly understand at least some of the scalability issues raised, and look forward to understanding more!). Greg From rem-conf-request@es.net Mon Nov 25 19:58:04 1996 Received: from gw.navio.com by osi-east.es.net with ESnet SMTP (PP); Mon, 25 Nov 1996 16:57:13 -0800 Received: (from proxy@localhost) by gw.navio.com (8.6.12/8.6.9) id QAA08805; Mon, 25 Nov 1996 16:56:57 -0800 Received: from lulu.navio.com(204.182.38.230) by tvsoft.com via smap (V1.3) id sma008799; Mon Nov 25 16:56:45 1996 Message-Id: <3.0.32.19961125165518.006d4f30@gw.navio.com> X-Sender: brianb@gw.navio.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 25 Nov 1996 16:55:19 -0800 To: Greg Minshall From: Brian Bulkowski Subject: Re: RTCP RR's Cc: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 01:39 PM 11/25/96 -0800, you wrote: >One thing that shouldn't get lost in this discussion is the use of RTCP for >understanding the current "state" of the network. This is useful for >debugging, as well as for engineering. A proposal that said "if there are one >speaker and n**n receivers, receivers shouldn't use RTCP to provide reception >information" would cause us to lose this information. I agree that it's useful. One point that I made earlier was that the existance of a huge, faulty network means we should have more, better diagnostic techniques, not fewer. However, I have trouble seeing a way to disentangle the web RTCP has cleverly woven. By relying on a symetric, multicast nature for both SSRC disambiguation and RTCP propagation, I have trouble seeing how RTCP will work in a network without multicast nature. The protocols I have to use (Aloha in specific) force that people who share the same wire don't see each other's packets. The client-side memory requirements are tricky as well, since I can't see a way to handle the issue without relying on the IP address of the sender; and if you use the sender IP addr and port as a disambiguator for receivers, why have an SSRC per at all? It is very easy to imagine a network monitering systems that work well in these environments. They would be similar to the ones in use in cable systems today. You can ping out certain branches (using SNMP instead of analog refraction techniques) on a regular basis (or when customers complain :-) to diagnose faults. This system is perfectly scaleable, and can be focused on trouble branches. Having a good RTP MIB (and no RTCP) would solve my problems nicely. In the networks I'm examining, there is not expected to be connectivity between client nodes, just between the head end and each client. Sure, it would be possible to build that connectivity, but the complexity would be prohibitive. I believe it is important to match the transport protocol characteristics with the network it runs on. These broadcast networks are almost completly unlike what we think of today as a "computer network". In many ways you are best off thinking about channel-attached 3270's. The fact that the web is (basically) a block mode device creates some fascinating synergy. You certanly remember how it was "easy" to write tn3270 on a bidirectional TCP/IP network, and very tough to write TELNET for VM/370. RTCP just doesn't fit in its current form. I believe RTCP needs flexibility, just like RTP has, to deal with these new networks. I am scared that people will write this off as a payload type issue. The only alternative I can see is a massive propigation of RTP multiplexor technology, which starts defeating the cool part of multicast IP + RTP. -brianb From rem-conf-request@es.net Tue Nov 26 01:49:50 1996 Received: from deception.hpcu.uq.edu.au by osi-east.es.net with ESnet SMTP (PP); Mon, 25 Nov 1996 22:49:13 -0800 Received: from deception.hpcu.uq.edu.au (1110@localhost [127.0.0.1]) by deception.hpcu.uq.edu.au (8.8.3/8.8.3) with ESMTP id QAA04334; Tue, 26 Nov 1996 16:48:56 +1000 Message-Id: <199611260648.QAA04334@deception.hpcu.uq.edu.au> X-Mailer: exmh version 1.6.5 12/11/95 To: rem-conf@es.net cc: Wilfred Brimblecombe Subject: SGI HPC Australian Users Meeting Keynote Talk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Nov 1996 16:48:54 +1000 From: "Dr. Rodney McDuff" SGI HPC Australian User Group Users Meeting Keynote Talk Date: 13:15 AEST (GMT-10) Friday 29 November 1996 George Couyant from SGI Melbourne and Ian Farquhar from SGI Sydney will be present. George will give the Keynote and Ian will also do a short talk. George Couyant will talk about the new Origin series machines. George will be followed by Ian who will talk about the tech support area. -- +-------------------------+------------------------------------------+ | _ ^ _ | Dr. Rodney McDuff | | |\ /|\ /| | Advanced Computational Modelling Centre | | \ | / | The University of Queensland | | \ | / | St. Lucia, Brisbane | | \|/ | Queensland, Australia. 4072. | | <--------+--------> | | | /|\ | TELEPHONE: +61 7 365 7415 | | / | \ | INTERNET:mcduff@bribie.hpcu.uq.edu.au | | / | \ | FACSIMILE: +61 7 365 1242 | | |/ \|/ \| | | | - v - | Ex ignorantia ad sapientiam | | | Ex luce ad tenebras | +-------------------------+------------------------------------------+ From rem-conf-request@es.net Tue Nov 26 09:04:21 1996 Received: from cismsun.univ-lyon1.fr by osi-east.es.net with ESnet SMTP (PP); Tue, 26 Nov 1996 06:03:39 -0800 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.12/8.6.12) id PAA20657 for rem-conf@es.net; Tue, 26 Nov 1996 15:03:27 +0100 Message-Id: <199611261403.PAA20657@cismsun.univ-lyon1.fr> Subject: sdr announces lifetime To: rem-conf@es.net Date: Tue, 26 Nov 1996 15:03:26 +0100 (MET) From: Lucia Gradinariu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 711 maybe i'm wrong but it seems that a conference announce is no long broadcasted after the conference starts ... or maybe there is something wrong in time definition when session announce is set up ?! (today's example is the IPv6 talk from Strasbourg, France advertized for 14hMET no way to connect from sdr at 14h30MET ) -------------------------------------------------------------------------------- Lucia GRADINARIU, Eng. CISM-Univ. Cl. Bernard Lyon1 voice:(33).72.43.13.69 Bat. 101 Bd. du 11 Novembre 1918 fax:(33).72.44.84.10 69622 Villeurbanne FRANCE email:lucia@univ-lyon1.fr http://www.univ-lyon1.fr/CISM/lucia --------------------------------------------------------------------------------- From rem-conf-request@es.net Tue Nov 26 09:30:34 1996 Received: from mail.kornet.nm.kr by osi-east.es.net with ESnet SMTP (PP); Tue, 26 Nov 1996 06:29:58 -0800 Received: from ring.kotel.co.kr (ring.kotel.co.kr [147.6.1.2]) by mail.kornet.nm.kr (8.6.12h2/8.6.12) with SMTP id XAA18411 for ; Tue, 26 Nov 1996 23:27:40 +0900 Received: from infosun.kotel.co.kr by ring.kotel.co.kr (4.1/RING-0.1) id AA00575; Tue, 26 Nov 96 23:33:17 KST Received: from ring.kotel.co.kr (titga5.kotel.co.kr) by infosun.kotel.co.kr (4.1/H2O-1.1) id AA21342; Tue, 26 Nov 96 23:31:19 KST Message-Id: <329AFF31.7C4F@infosun.kotel.co.kr> Date: Tue, 26 Nov 1996 23:31:13 +0900 From: "Kim, Sung-Won" Reply-To: swkim@infosun.kotel.co.kr Organization: Korea Telecom R&D Group. Tech. Inf. Section X-Mailer: Mozilla 3.0Gold (Win95; I) Mime-Version: 1.0 To: rem-conf@es.net Subject: Mbone Multicasting: Korea Telecom International Symposium '96 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit We are please to notice that we are going to multicast follow symposium via Mbone multicasting. You can see this by connect to KTIS session. we hope there are many access to this symposium and every one of you can find it as valuable. * Title : Korea Telecom International Symposium '96 * Theme : Multimedia Telecommunications Services and Technologies Korea Telecom has long been a leader in the field of telecommunications services and emphasized R&D activities providing up-to-date communication technologies. To exchange and promote the state-of-the-art R&D activities in information and telecommunications technologies all over the world, Korea Telecom holds an international symposium called Korea Telecom International Symposium (KTIS) every year since 1991. The sixth KTIS, KTIS'96, will be held as follows focusing upon multimedia technologies and services. $)C !$Openning Session:GMT 28 Nov., 01:00-03:00 !$Session I : GMT 28 Nov., 04:00-08:00 Multimedia Network !$Session II : GMT 29 Nov., 01:00-03:00 Multimedia Technologies !$Session III: GMT 29 Nov., 04:00-08:00 Multimedia Applications and Services * Period: November 28-29, 1996 * Venue : Main Hall, Korea Telecom R&D Group, Seoul, Korea For more detail information please visit our homepage 'http://ktwww.kotel.co.kr/OVER/KTIS/ktis96_e.html' From rem-conf-request@es.net Tue Nov 26 12:00:28 1996 Received: from aruba.lerc.nasa.gov by osi-east.es.net with ESnet SMTP (PP); Tue, 26 Nov 1996 08:59:45 -0800 Received: from captiva.lerc.nasa.gov by aruba.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id LAA16766; Tue, 26 Nov 1996 11:58:00 -0500 (EST) Received: from jmudry1.lerc.nasa.gov by captiva.lerc.nasa.gov with SMTP (NASA LeRC 8.7.4.1/2.01-local) id LAA25330; Tue, 26 Nov 1996 11:57:39 -0500 (EST) Message-Id: <2.2.32.19961126165738.00680c00@popserve.lerc.nasa.gov> X-Info: IDE / NASA Lewis Research Center X-Sender: prmudry@popserve.lerc.nasa.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Nov 1996 11:57:38 -0500 To: chiueh@cs.sunysb.edu, chlamtac@BCN.BU.EDU, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, cost237-transport@comp.lancs.ac.uk, danzig@pollux.usc.edu, dbarbara@bellcore.com, dboff@ddn-pac.ddn.mil, dbworld@cs.wisc.edu, eddie.hsu@jpl.nasa.gov, end2end-interest@isi.edu, epitoura@cc.uoi.gr, f-troup@aurora.cis.upenn.edu, grossman@uic.edu, helm@seas.gwu.edu, hfk@research.att.com, hipparch@sophia.inria.fr, ian@cesdis1.gsfc.nasa.gov, jimf@aro.ncren.edu.tw, mhd@seas.smu.edu, msmith@osat.hq.nasa.gov, nishida@dc.kdd.com, padmanab@joyride.CS.Berkeley.EDU, pat.gary@gsfc.nasa.gov, ralonso@peanut.sarnoff.com, randy@cs.Berkeley.edu, rem-conf@es.net, rgopal@hns.com, rhoward@sses2.cta.com From: John J Mudry Subject: AGENDA - Comm. Services for 21st Century COMMUNICATIONS SERVICES FOR THE 21ST CENTURY: AN INFORMATION EXCHANGE December 3, 1996 - 5:30 p.m. McCormick Place, Room N228 Chicago, Illinois AGENDA 5:30 OPENING REMARKS =B7 Don Schomer, ECC, RSNA =B7 John Mudry, NASA,LeRC 5:35 PANEL 1 - COMMUNICATIONS SERVICE PROVIDERS =B7 Current/Planned Communications Services =B7 Communications Service Improvements/Breakthroughs =B7 Satellites as Extension of Terrestrial Telecommunications Networks =B7 Communications Services for Telemedicine =B7 Communications Industry Challenges Panelists: Rick Smallcomb - SPACEWAY, Hughes Communications Hardi Mann - Ameritech Joe Judge - CyberStar, Space Systems Loral Steve Spak - Bell Atlantic John Esposito - GE*Star, GE Americom Enrique Cuevas - AT&T Labs Steve Quagliata - Teleport Comm. Group =09 6:25 AUDIENCE QUESTION & ANSWER=20 6:35 PANEL 2 - COMMUNICATIONS SERVICE USERS =B7 Current Uses of Communications Services =B7 Communications Requirements for Telemedicine =B7 Vision for Telemedicine Communications Needs in the Year 2000 =B7 Medical Community Challenges in Telemedicine Panelists: Dr. Kathy Theade - Saint Vincent Hosp. and Health Ctr. Kevin Cleary - Georgetown Univ. Med. Cntr. Rodney Long - National Library of Medicine Dr. Bijoy Khandheria - Mayo Clinic Jerome R. Cox, Jr. - Washington Univ. - St. Louis =09 =09 7:25 AUDIENCE QUESTION & ANSWER=20 7:35 NETWORKING OPPORTUNITY & RECEPTION 8:30 CLOSING REMARKS From rem-conf-request@es.net Tue Nov 26 13:52:54 1996 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Tue, 26 Nov 1996 10:46:12 -0800 Received: from ibeam.intel.com (ibeam.jf.intel.com [134.134.208.3]) by ormail.intel.com (8.8.3/8.7.3) with SMTP id KAA05828; Tue, 26 Nov 1996 10:44:35 -0800 (PST) Received: from zcr.jf.intel.com by ibeam.intel.com with smtp (Smail3.1.28.1 #6) id m0vSSWF-000RzHC; Tue, 26 Nov 96 10:46 PST Received: by zcr.jf.intel.com with Microsoft Mail id <01BBDB86.DD782600@zcr.jf.intel.com>; Tue, 26 Nov 1996 10:44:57 -0800 Message-ID: <01BBDB86.DD782600@zcr.jf.intel.com> From: Chunrong Zhu To: "'internet-drafts@ietf.org'" Cc: "rem-conf@es.net" , "'casner@precept.com'" , "'czhu@ibeam.intel.com'" Subject: draft-ietf-avt-rtp-payload-02.txt Date: Tue, 26 Nov 1996 10:44:55 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BBDB86.DD7B3340" ------ =_NextPart_000_01BBDB86.DD7B3340 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, I am posting the v02 of "RTP payload format for H.263 video streams" (previously draft-ietf-avt-rtp-payload-01.txt). This version reflected changes in ITU H.263 spec on motion vector ranges in unrestricted motion vector optional mode. We also added 2 bit version fields in H.263 payload header. We understand this would impact existing implementations, so if anyone has any comments or concern on the changes, please send email to czhu@ibeam.intel.com. I would like to thank Jerry Shapiro from Aware, Inc for pointing out issues on unrestricted motion vector and SAC. Regards. Chad Zhu Senior Software Engineer Intel Corporation ------ =_NextPart_000_01BBDB86.DD7B3340 Content-Type: text/plain; name="rtp263id.txt" Content-Transfer-Encoding: 7bit Internet Engineering Task Force Audio-Video Transport WG INTERNET-DRAFT C. Zhu Intel Corp. November 25, 1996 Expires: May 25, 1997 RTP Payload Format for H.263 Video Stream Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Abstract This document specifies the RTP payload format for encapsulating H.263 bitstreams in the Real-Time Transport Protocol (RTP). Three modes are defined for RTP H.263 payload header. An RTP packet can use one of the three modes for H.263 video streams depending on the desired performance characteristics and H.263 encoding options employed. The shortest header mode (Mode A) supports fragmentation at Group of Block (GOB) boundaries. The long header modes (Mode B and C) support fragmentation at Macroblock (MB) boundaries. Zhu [Page 1] Internet Draft RTP Payload for H.263 November 25, 1996 1. Introduction This document describes a scheme to packetize an H.263 video stream for transport using RTP [1]. H.263 video stream is defined by ITU-T Recommendation H.263 (referred to as H.263 in this document) [4] for video coding at very low bit rate. RTP is defined by the Internet Engineering Task Force (IETF) to provide end-to-end network transport functions suitable for applications transmitting real-time data over multicast or unicast network services. The complete specification of RTP for a particular application will require a profile specification document [3], a payload format specification, and an RTP protocol document [1]. This document is intended to serve as the payload format specification for H.263 video streams. 2. Definitions For the purpose of this document, the following definitions apply: CIF: Common Intermediate Format. For H.263, a CIF picture has 352 x 288 pixels for luminance, and 176 x 144 pixels for chrominance. QCIF: Quarter CIF source format with 176 x 144 pixels for luminance and 88 x 72 pixels for chrominance. sub-QCIF: picture source format with 128 x 96 pixels for luminance and 64 x 48 pixels for chrominance. 4CIF: picture source format with 704 x 576 pixels for luminance and 352 x 288 pixels for chrominance. 16CIF: picture source format with 1408 x 1152 pixels for luminance and 704 x 576 pixels for chrominance. GOB: for H.263, a Group of Blocks (GOB) comprises of k*16 lines, depending on the picture format (k=1 for QCIF, CIF and sub-QCIF, k=2 for 4CIF and k=3 for 16CIF). MB: a macroblock (MB) relates to four blocks of luminance and the spatially corresponding two blocks of chrominance. Each block consists of 8x8 pixels. 3. Design Issues for Packetizing H.263 Bitstream H.263 is based on the ITU-T Recommendation H.261 [2] (referred to as H.261 in this document). Although it employs similar techniques to reduce both temporal and spatial redundancy, there are several major differences between the two algorithms that impact the design of packetization schemes significantly. This section summarizes those differences. Zhu [Page 2] Internet Draft RTP Payload for H.263 November 25, 1996 3.1 Optional Features of H.263 In addition to the basic source coding algorithms, H.263 supports four negotiable features to improve performance: Advanced Prediction, PB frames, Syntax-based Arithmetic Coding, and Unrestricted Motion Vectors. They can be used in any combination. Advanced Prediction(AP): four motion vectors instead of one can be used for some macroblocks in the frame. This feature makes recovery from packet loss harder, because more redundant information has to be preserved at the beginning of the packet when fragmenting at macroblock boundaries. PB frames: two frames ( P frame and B frame) are coded into one bitstream with macroblocks from the two frames interleaved. From a packetization point of view, a MB from the P frame and a MB from the B frame must be treated together because each MB for the B frame are coded based on the corresponding MB for the P frame. A means must be provided to ensure proper rendering of two frames in the right order. Also if part of this combined bitstream is lost, it will effect the two frames, and possibly more. Syntax-based Arithmetic Coding (SAC): Huffman codes are not the only choice for variable length coding. When the SAC option is on, the resultant run value pair after quantization of Discrete Cosine Transform (DCT) coefficients will be coded differently from Huffman codes, but the macroblock hierarchy will be preserved. Since context variables are only synchronized before fixed length codes in the bitstream, any fragmentation at variable length codes will result in difficulty in decoding in the presence of packet loss without carrying the values of all the context variables in each packet header. Unrestricted motion vector feature also has impact on packetization because of larger range of motion vector than normal. To enable proper decoding of packets received without dependency on previous packets, the use of these optional features is signaled in the H.263 payload header, as described in section 5. 3.2 GOB Numbering In H.263, each picture is divided into groups of blocks (GOB). GOBs are numbered by vertical scan of the GOBs, starting with the upper GOB and ending with the lower GOB. In contrast, a GOB in H.261 is composed of three rows of 16x16 MB for QCIF, and three half rows of MB for CIF format. Like H.261, a GOB is divided into macroblocks in H.263. The definition of a macroblock in H.263 is the same as in H.261. Each GOB in H.263 can have a fixed GOB header, but unlike H.261 the use of the header is optional. If the GOB header is present, it may or may not start on a byte boundary. Byte alignment can be achieved by proper bit stuffing by the encoder, but it is not required. Zhu [Page 3] Internet Draft RTP Payload for H.263 November 25, 1996 In summary, a GOB in H.263 is defined and coded with finer granularity with the same source format, thus resulting in more flexibility for packetization than with H.261. 3.3 Motion Vectors Encoding Differential coding is used to code motion vectors as variable length codes. Unlike in H.261, where each motion vector is predicted from the previous MB in the GOB, H.263 employs a more flexible prediction scheme, where three candidate predictors are used instead of one. It is done differently depending on the presence of GOB header. If the GOB header is included for a GOB, motion vectors are coded with reference to MBs in the current GOB only. But if the GOB header is not present for the current GOB, three motion vectors must be available to decode one macroblock, where two of them are from the previous GOB. To decode the whole inter-coded GOB, all the motion vectors must be available from the previous GOB. This can be a major problem for a packetization scheme like the one defined for H.261 when packetizing at MB boundaries. Let's assume a packet starts with one MB but the GOB header is not coded. If the previous packet is lost, then all the motion vectors to predict the motion vector for the MBs in this GOB are not available. In order to decode the received MBs correctly, all the motion vectors for the previous GOB would have to be saved at the beginning of the packet. This would be very expensive and unacceptable in terms of bandwidth overhead. The encoding strategy of each H.263 codec implementation is beyond the scope of this document, even though it has very significant impact on visual quality in the presence of packet loss. However, we strongly recommend use of the GOB header for every GOB at the beginning of a packet to address these problems. 3.4 Macroblock Address As specified by H.261, macroblock address (MBA) is encoded with a variable length code to indicate the position of a macroblock within a group of blocks in the H.261 bitstream. H.263 does not code the MBA explicitly, but the macroblock address within a GOB is necessary to recover the decoder state in the presence of packet loss when fragmenting at MB boundaries. Therefore, this information must be included in the H.263 payload header for two of the modes (Mode B and Mode C as described in section 5) that allow packetization at MB boundaries. Zhu [Page 4] Internet Draft RTP Payload for H.263 November 25, 1996 4. Usage of RTP When transmitting H.263 video streams over the Internet, we will directly packetize the output of the encoder. All the bits resulting >from the bitstream including the fixed length codes and variable length codes (Huffman codes, or SAC if SAC is used) will be included in the packet. Also we do not intend to multiplex audio and video signals in the same packets, as UDP and RTP provide a much more efficient way to achieve multiplexing. RTP does not guarantee a reliable and orderly data delivery service, so a packet might get lost in the network. To achieve a best-effort recovery from packet loss, the decoder needs assistance to proceed with decoding of other packets that are received. Thus it is desirable to be able to process each packet independent of other packets. Some frame level information is included in each packet, such as source format and flags for optional features to assist the decoder in operating correctly and efficiently in presence of packet loss. The flags for H.263 optional features also provide information about coding options used in the H.263 video streams that can be used by session management tools. The H.263 video stream will be carried as payload data within the RTP packets. A new H.263 payload header is defined in section 5, H.263 payload header. This section defines the usage of RTP fixed header and H.263 video packet structure. 4.1 RTP Header usage Each RTP packet starts with a fixed RTP header. The following fields of the RTP fixed header are used for H.263 video stream: Marker bit (M bit): The Marker bit of the RTP header is set to 1 when the current packet carries the end of current frame. 0 otherwise. Payload Type (PT): The Payload Type shall specify H.263 video payload format. Timestamp: The RTP Timestamp encodes the sampling instance of the first video frame contained in the RTP data packet. The RTP timestamp may be the same on successive packets if a video frame occupies more than one packet. For H.263 video stream, the RTP timestamp is based on a 90 kHz clock, the same as that of RTP payload for H.261 stream. 4.2 Video Packet Structure H.263 compressed bitstream is carried as payload within each RTP packet. For each RTP packet, the RTP header is followed by the H.263 payload header, which is followed by the standard H.263 compressed bitstream. The size of the H.263 payload header is variable depending on modes used as detailed in the next section. The layout of the RTP H.263 video packet is shown as: Zhu [Page 5] Internet Draft RTP Payload for H.263 November 25, 1996 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H.263 Payload Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H.263 stream | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. H.263 Payload Header For H.263 video streams, each RTP packet carries only one H.263 video packet. The H.263 payload header is always present for each H.263 video packet. Three formats (Mode A, Mode B and Mode C) are defined for RTP H.263 payload header. In Mode A, a H.263 payload header of four bytes is present before actual compressed H.263 video bitstream in the packet. It allows fragmentation at GOB boundaries. In Mode B, a eight byte H.263 payload header is used and each packet starts at MB boundaries with the PB frame option off. Finally, Mode C with a 12 bytes header is provided to support fragmentation at MB boundaries for frames that are coded with the PB frame option on. The mode is indicated by the F field and P field in the first two bits of the header. The three modes can be intermixed for one compressed frame. All the client application are required to be able to receive packets in all three modes, but decoding of Mode C packets is optional because PB-frame is an optional feature of H.263 decoder. In this section, the H.263 payload format is shown as rows of 32-bit word. Each word is transmitted in network byte order with the most significant byte shown at the left in the following diagrams. 5.1 Mode A In this mode, H.263 bitstream will be packetized at GOB boundaries. In other words, each packet will start at the beginning of a GOB, and it can carry one or more MBs or GOBs. Only four bytes are used for the header. Mode A can be used with or without PB frame option. For those GOBs that are smaller than network packet size, this mode is recommended. The H.263 payload header definition for Mode A is shown as follows with F=0. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V |F|P|I|SBIT |EBIT | SRC |U|A|S|R |DBQ| TRB | TR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zhu [Page 6] Internet Draft RTP Payload for H.263 November 25, 1996 V: 2 bit Version number, set to 0 for this version of RTP H.263 payload header. F: 1 bit The flag bit indicates the format of the header. F=0, Mode A, F=1, Mode B or Mode C. P: 1 bit Optional PB-frame mode as defined by the H.263 [4]. "0" implies normal I or P frame, "1" PB-frame. When F=1, P also indicates modes. Mode B if P=0, Mode C if P=1. I: 1 bit. Set to 1 if current picture is intra-coded. Otherwise 0. Notice this is opposite to the picture coding type in PTYPE as defined within the H.263 bitstream [4]. SBIT: 3 bits Start bit position specifies number of bits that should be ignored in the first data byte. EBIT: 3 bits End bit position indicates number of bits that should be ignored in the last data byte. SRC : 3 bits Source format specifies the resolution of the frames contained as defined by the H.263 [4]. U: 1 bit Unrestricted Motion Vector mode as defined by H.263 [4]. "0" off, "1" on. A: 1 bit Optional Advanced Prediction mode as defined by H.263 [4]. "0" off, "1" on. S: 1 bit Optional Syntax-based Arithmetic Code mode as defined by the H.263 [4]. 0" off, "1" on. R: 2 bits Reserved, must be set to zero. DBQ: 2 bits Differential quantization parameter to calculate quantizer for the B frame based on quantizer for the P frame, when PB frame option is on. The value should be the same as DBQUANT defined by the H.263 [4]. Set to zero if PB frame option is off. Zhu [Page 7] Internet Draft RTP Payload for H.263 November 25, 1996 TRB: 3 bits Temporal Reference for the B frame as defined by the H.263 [4]. Set to zero if PB frame option is off. TR: 8 bits Temporal Reference for the P frame as defined by the H.263 [4]. Set to zero if the PB frame option is off. 5.2 Mode B In this mode, the H.263 stream can be fragmented at MB boundaries. Thus necessary information is needed at the start of a packet to recover the decoder internal state in the presence of packet loss. It is intended for those GOBs whose sizes are larger than the maximum packet size allowed in the underlying protocol. This mode can only be used with PB frame option off. Mode C as defined in the next section can be used to fragment at MB boundaries with PB frame option on. The H.263 payload header definition for Mode B is shown as follows with F=1 and P=0: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V |F|P|I|SBIT |EBIT | SRC | QUANT | GOBN | MBA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|A|S|R| HMV1 | VMV1 | HMV2 | VMV2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following fields are defined the same as in Mode A: F, P, SBIT, EBIT, SRC, I, A, S, V and U. Other fields are defined as follows: QUANT: 5 bits Quantization value for the first MB coded at the starting of the packet. Set to 0 if the packet begins with a GOB header. This is the equivalent of GQUANT defined by the H.263 [4]. GOBN: 5 bits GOB number in effect at the start of the packet. GOB number is specified differently for different resolutions. See H.263 [4] for details. MBA: 8 bits The absolute address of the first MB within its GOB, counting from 0. HMV1, VMV1: 7 bits each. Horizontal and vertical motion vector predictors for the first MB coded in this packet from the MB on the left. The same as MV1 defined by H.263 [4]. Zhu [Page 8] Internet Draft RTP Payload for H.263 November 25, 1996 HMV2, VMV2, 7 bits each. Horizontal and vertical motion vector predictors from the block or MB on the left of block number 3 in the current MB when advanced prediction option is on. They are the same as MV1 defined for block number 3 in H.263 [4]. This is needed because block number 3 in the first MB needs the motion vector predictor from the block to its left, as block number 1. These two fields are not used when advanced prediction is off and must be set to 0. See the H.263 [4] for block organization in a frame. R: 1 bit Reserved, must set to zero. 5.3 Mode C In this mode, H.263 stream can be fragmented at MB boundaries of P frames when the PB frame option is on. It is intended for those GOBs whose sizes are larger than the maximum packet size allowed in the underlying protocol. H.263 payload header definition for Mode C is shown as follows with F=1 and P=1: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V |F|P|I|SBIT |EBIT | SRC | QUANT | GOBN | MBA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|A|S|R| HMV1 | VMV1 | HMV2 | VMV2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR |DBQ| TRB | TR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following fields are defined the same as in Mode A: F, P, SBIT, EBIT, SRC, I, A, S, U, V, R, TR, DBQ, TRB, and the rest of the fields are defined the same as in Mode B, except field RR of 19 bits is reserved and its value must be zero. 5.4 Selection of Modes for the H.263 Payload Header Packets with different modes can be intermixed. The modes shall be selected carefully based on performance characteristics, H.263 coding modes and underlying network protocols. We strongly recommend use of Mode A whenever possible. The major advantage of Mode A over Mode B and C is its simplicity. The header is one half and one third of the size of Mode B and C respectively. Transmission overhead is reduced and the savings may be very significant when working with very low bit rates, especially when low latency is desired. Zhu [Page 9] Internet Draft RTP Payload for H.263 November 25, 1996 Another advantage of Mode A is that it simplifies error recovery in the presence of packet loss. The internal state of the decoder can be recovered at GOB boundaries instead of having to synchronize with MBs as in Mode B and C. The GOB headers and the picture start code are easy to identify, and their presence will normally cause the H.263 decoder to re-synchronize its internal states. Requiring the decoder to synchronize its internal states at MBs introduces extra overhead and complexity for the decoder. Mode A shall be used for packets starting with a GOB of size smaller than the network packet size. The major disadvantage of Mode A is lack of flexibility in packetization when a GOB can not fit in a network packet. Mode B has the advantage of flexibility with fragmentation at MB boundaries with PB frame option off. This mode is necessary when a GOB is larger than the network packet size. It has the disadvantage of higher overhead with a long header of 8 bytes. For small packets, this may not be desirable. Mode C is the same as B, except it allows fragmentation with PB option on at the price of 4 additional bytes. Finally, we would like to emphasize that recovery from packet loss will depend on the decoder's ability to use the information provided in the H.263 payload header within the RTP packets. 6. References [1] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP : A Transport Protocol for Real-Time Applications, RFC 1889. [2] Video Codec for Audiovisual Services at px64 kbits/s, ITU-T Recommendation H.261, 1993 [3] RTP Profile for Audio and Video Conference with Minimal Control, RFC 1890. [4] Video Coding for Low Bitrate Communication, ITU-T Recommendation H.263, 1995 [5] T. Turletti, C. Huitema, RTP Payload Format for H.261 Video Stream. RFC 2032. 7. Author's Address Chunrong "Chad" Zhu Mail Stop: JF2-78 Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA Zhu [Page 10] Internet Draft RTP Payload for H.263 November 25, 1996 Email: czhu@ibeam.intel.com Tel: (503) 264-8849 Fax: (503) 264-6067 Zhu [Page 11] ------ =_NextPart_000_01BBDB86.DD7B3340-- From rem-conf-request@es.net Tue Nov 26 18:05:42 1996 Received: from monitor.internaut.com (actually Cust108.Max16.Seattle.WA.MS.UU.NET) by osi-east.es.net with ESnet SMTP (PP); Tue, 26 Nov 1996 15:05:03 -0800 Received: (from aboba@localhost) by monitor.internaut.com (8.7.5/8.6.12) id PAA08433 for rem-conf@es.net; Tue, 26 Nov 1996 15:01:51 -0800 (PST) Date: Tue, 26 Nov 1996 15:01:51 -0800 (PST) From: Bernard Aboba Message-Id: <199611262301.PAA08433@monitor.internaut.com> To: rem-conf@es.net Subject: Summary of RTP scalability discussions I thought I would summarize some of the proposals and issues relating to RTP scalability in the draft that follows. Comments appreciated. INTERNET-DRAFT Bernard Aboba Microsoft Corporation Alternatives for Enhancing RTP Scalability 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as , and expires June 1, 1997. Please send com- ments to the authors. 2. Abstract This document discusses current issues with RTP scalability as well as describing the advantages and disadvantages of possible solutions. 3. Requirements In evaluating a solution to the RTP scaling problem, it is important to have an understanding of the requirements that a proposed solution must meet. This document proposes three requirements: Decrease in convergence time Decrease in effective RTCP sending population Improvement in receiver reporting information 3.1. Decrease in convergence time Currently RTCP relies on multicasting of receiver reports to establish a receiver-population estimate. This shared-state is then used by receivers to establish the receiver reporting interval. This mechanism appears to function satisfactorily for conferences with several thou- sand members. However, for larger conferences the result is very slow convergence of receiver population estimates, resulting in long Aboba [Page 1] INTERNET-DRAFT 26 November 1996 receiver reporting intervals, and RTCP bandwidth usage well in excess of the 5 percent recommendation. This is particularly problematic for dialup clients, which can experience severe RTCP-induced congestion. For example, in a large conference the algorithm described in [1] ini- tially results in a flood of reports from receivers joining the con- ference, even though some random delay is imposed. This is because the delay interval will initially be set low since receivers will set the initial membership estimate to one. For dialup users, the result is severe RTCP-induced congestion. However, even if all available band- width is devoted to listening to RTCP receiver reports, a user con- nected via a 14.4 Kbps modem can only receive a maximum of 1440 receiver reports a minute (assuming 60 octet receiver reports). In reality, the number of actual reports that can be received will be much less, since it is likely that the user will want to receiver other traffic, such as audio/video from the conference they are attempting to subscribe to. This is likely to reflect itself in having RTCP packets set at lower priority than RTP packets, resulting in dropping of RTCP packets during periods of congestion. Therefore in reality a more realistic maximum convergence rate might be closer to 200 receiver reports a minute. This implies very long convergence times. In a 20,000 user conference, the algorithm described in [1] could take well over an hour and a half to converge. By the time we have achieved convergence, the average reporting interval will be 1.9 hours. 3.2. Decrease in effective RTCP sending population Today the MBONE uses DVMRP as its multicast routing protocol. DVMRP generates forwarding cache entries on demand for each (source network, destination group) pair, and supports source-specific prune messages. The typical forwarding cache expiration time is 200 seconds. Since the current RTCP mechanism requires each RTP receiver to become a sender on the RTCP group, for large conferences, the result is cre- ation of groups with a large number of senders. For example, an RTP session with a single sender and 20,000 listeners would result in a companion RTCP group with 20,001 senders and receivers. Even given the slow convergence of receiver population estimates, it is likely that the reporting interval will exceed the forwarding cache expiration time within the first few minutes after conference initia- tion. As a result, only a portion of all (source network, destination group) pairs would be cached by a DVMRP implementation at a given time. Nevertheless, the router will expend considerable resources in adding and flushing forwarding cache entries, as well as in responding to source-specific prune requests. While future versions of DVMRP may prove more scalable, it is unlikely that these versions will be widely deployed within the next 18 months. As a result, it would desirable for an RTP scaling solution to provide for a decrease in the number senders on the RTCP group. Aboba [Page 2] INTERNET-DRAFT 26 November 1996 3.3. Improvement in receiver reporting information The RTCP receiver report mechanism provides important information on listenership, reception quality, and bandwidth availability. This information is important useful both for engineering and business pur- poses. Engineers use reception quality information to diagnose prob- lems with the network. Sending systems can use reception quality and bandwidth availability information to modify transmission parameters such as compression ratio and sending rate. Business people use infor- mation on listenership to track the size of the audience, and recep- tion quality information to measure the quality of the user experi- ence. Since in large conferences the algorithm described in [1] leads to underestimates of the receiver population and infrequent receiver reporting, it can be argued that it does not meet the requirements for accurate and timely receiver reporting. Therefore any scaling "improvement" should not hamper the ability to collect this informa- tion, and probably should be expected to result in improved reporting. 4. Scaling alternatives Several alternatives have been proposed for improving the scalability of RTCP. These include: Turning off RTCP receiver reports Improved convergence algorithms Use of separate multicast groups for receiver and sender reports Unicasting of receiver reports Selective reporting Use of TTL scoping and summary messages Use of RTP translators These alternatives are discussed in turn. 4.1. Turning off RTCP receiver reports In some applications (such as satellite transmission) it may not be possible to offer an upstream channel for transmission of RTCP receiver reports. As a result, it may be desirable to allow receiver reporting to be turned off. Since there is no receiver reporting, there would be no way to estimate the receiver population. Influence on RTCP receivers could be exercised via the SDP announce- ment mechanism. For example, Mark Handley has proposed that the ses- sion profile specified in SDP via the "m=" line be used to define the desired RTCP behavior. This would allow for turning off of RTCP receiver reports, or another desired mechanism. While this proposal would eliminate the congestion problem for receivers, it would deprive interested parties of information on lis- tenership and reception quality. This will prevent senders from making Aboba [Page 3] INTERNET-DRAFT 26 November 1996 adjustments to their transmission parameters, and would also prevent RTP monitors from providing listenership estimates needed to justify advertising rates. 4.2. Improved convergence algorithms Just as non-linear equation solvers can benefit from improved algo- rithms, it may be possible to improve RTP receiver population esti- mates via improvements in the algorithm. These may include improving the initial population estimate, as well as improve the algorithm by which receivers estimate the overall population. Currently the receiver population estimate has an initial value of 1, but it is possible for an initial population estimate to be supplied in the session announcement. Successive population estimates could then be derived via an averaging of the initial estimate and the receiver's own estimate, so that the effect of the initial estimate would die out over time. It is also possible to improve the speed of convergence by allowing the receiver to use information on the rate at which receiver reports are being sent, and incorporate this into the population estimate and receiver reporting interval. For example, due to bandwidth limita- tions, receivers on higher bandwidth connections have greater knowl- edge of the overall receiver population. Thus if a receiver were to note a receiver report from a system advertising high bandwidth avail- ability, that report could be weighed more heavily in determining the overall population estimate. It is also possible to incorporate the receiver report rate into the reporting interval calculation. For example, if my current population estimate results in a receiver reporting interval of 3 minutes, and I am receiving 200 receiver reports/minute, it may be desirable to incorporate the rate of receiver reports into my calculations, increasing the reporting interval accordingly. However, the utility of such methods is limited in the case of dialup clients, since they will only be able to receive a modest number of receiver reports/minute, and thus the rate at which receiver reports are flowing in may not be reflective of the overall population. Thus, while an improved initial population estimate would result in improved convergence times, were the initial estimate to be way off, converging to a better estimate could still take a long time. This leads to the conclusion that we need to be able to make better use of those receiver reports that can be received. Thus while this proposal could lessen the congestion problem for higher-bandwidth receivers, it would not necessarily improve things markedly for dialup clients, and would not result in a lower number of senders on the RTCP receiver report group. Aboba [Page 4] INTERNET-DRAFT 26 November 1996 4.3. Use of separate multicast groups for receiver and sender reports Currently RTCP sender and receiver reports are sent to the same multi- cast group, and both RTP senders and receivers join this group. Were sender and receiver reports to be multicast on different groups, RTP receivers could be allowed to only join the sender report group, thus allowing them to avoid listening to receiver report traffic. RTP senders would still join both groups in order to receive feedback on listenership and transmission quality, and would need to provide information on the estimated receiver population within the sender reports. While this proposal would lessen the congestion problem for receivers, it would not improve things for senders who could still be deluged. It also would only result in improved convergence of receiver population estimates to the extent that senders can be assumed to have higher bandwidth connections than receivers. Finally, it would not result in a lower number of senders on the RTCP receiver report group. 4.4. Unicasting of receiver reports Instead of multicasting receiver reports, it is possible to unicast them back to the senders. This would allow RTP listeners to avoid receiver report traffic, while RTP senders would still receive feed- back on listenership and transmission quality. In order to control the receiver report transmission rate, senders would need to provide information on the estimated receiver population within sender reports. While this proposal would lessen the congestion problem for receivers, it would not necessarily improve things for senders who could still be deluged. It also would only result in improved convergence of receiver population estimates to the extent that senders can be assumed to have higher bandwidth connections than receivers. However, it would elimi- nate multicasting of RTCP receiver reports, which will be of benefit to overtaxed routers. 4.5. Selective reporting RTCP receiver reports serve multiple purposes. One of these is to pro- vide information on listenership; another is to provide information on reception quality and bandwidth availability. Given that receiver reporting intervals will tend to be very long for large conferences, it can be argued that absent an emergency, it makes sense to provide information on listenership, reception quality and bandwidth avail- ability within the RTCP Bye message. Thus on leaving the conference, the receiver would send a message providing information on the time period in which they joined the conference, the overall reception quality and other information. Conventional receiver reports would then either not be sent at all, or would be sent with a TTL of 1. How- ever, in order to supply engineers with timely information on network- related problems, it is necessary to add a mechanism by which Aboba [Page 5] INTERNET-DRAFT 26 November 1996 receivers could report packet losses exceeding some threshold. While this proposal would lessen the congestion problem at the begin- ning of a session, it could result in a deluge of receiver reports toward the end of the session. Given that no receiver population esti- mate would be available, it appears that this approach could actually worsen convergence times, unless it were combined with some kind of summarization mechanism. It would also not reduce the number of RTCP senders. 4.6. Use of TTL scoping and summary messages In this approach, RTCP receiver reports would be sent with a TTL of 1, and a designated summarizer would be elected to provide summary reports with a larger TTL. This approach has the advantage of increas- ing the leverage of those RTCP receiver reports that are sent, and is likely to be particularly effective for conferences in which member- ship is densely distributed. However, in sparsely distributed confer- ences, the effect of summarization will be small unless multiple lev- els of summarization are used. The designated summarizer would not necesarily be a router; it could also be another receiver, although this brings up the possibility of how a new summarizer could be elected if the current summarizer leaves the conference. Since in this scheme receiver reports are not forwarded, non- summarizing RTP receivers should use the population estimate gleaned from local scope reports to calculate their reporting interval. Summa- rizers and RTP senders will then use global estimates gleaned from global scope summary reports to calculate their reporting interval. A recommended bandwidth allocation for reporting is 25 percent for sender reports, 25 percent for summary reports, and 50 percent for receiver reports. Since this proposal decreases the scope of RTCP announcements, it would substantially reduce the congestion problem. It would also reduce the number of RTCP senders visible to the multicast backbone, and would decrease convergence times, since those messages that were sent would include more information on the receiver population. How- ever, it would also require substantial modifications in RTP client behavior. 4.6.1. Summary reports Via the use of summary reports, privacy can be provided while simulta- neously providing senders with improved listenership and receiver quality reporting. This is possible because in the existing implemen- tation much of the information gained from receiver reports is redun- dant. For example, if congestion results in packets being dropped on a particular link, then all receivers downstream from that link will report the same problem. This overabundance of redundant information obscures the information of greatest interest, which is information on global listenership and reception quality. Via introduction of summary Aboba [Page 6] INTERNET-DRAFT 26 November 1996 reports, it is possible to provide more accurate and timely reporting on listenership and reception quality. Information useful in summary reports would include: Total number of systems being summarized Packets received and lost Histogram of reception quality (fraction lost) Histogram of receiver bandwidth Information on users registering The total systems summarized number is used in order to provide for faster convergence times. Information on packets received and lost will typically be used by network engineers looking to diagnose prob- lems with the MBONE. The histograms of reception quality and receiver bandwidth are propagated in order to allow senders to deduce informa- tion relating to the global user experience. In order to allow for location of individuals participating in a conference, the summarizer may wish to relay information on the users in the conference. Alterna- tively, it may register users in a directory service via use of the LDAP extensions defined in [4]. 4.7. Use of RTP translators Through the use of RTP translators, it is possible to divide RTP receivers into areas in much the same way as is accomplished by OSPF. Through the use of summary receiver reports, information on listener- ship and receiver report quality can be propagated between areas while reducing RTCP bandwidth usage and the RTCP sending population on the MBONE. In order to insulate receivers within an area from external receiver reports, the RTP translator must filter external receiver reports, while allowing external summary reports and sender reports to pass through. Similarly, the RTP translator will listen to receiver reports generated from within its area, but will not pass them on to external areas. Instead, it would issue to external areas two types of summary reports. The first will be based on the packets it receives and will be identical to a conventional receiver report, except for the use of the summary report type; the second will be a true summary report based on area receiver reports. It is useful to allow receiver reports from RTP translators to pass through so as to allow diagnosis of internal distribution problems. The RTP translator will allow internal sender reports to pass through unmodified. The introduction of RTP translators has several advantages: Improved convergence of the receiver population estimate Decreased RTCP bandwidth Improved privacy Listenership and reception quality information available to senders While most of the above advantages are also available in the receiver Aboba [Page 7] INTERNET-DRAFT 26 November 1996 summary approach, one advantage of the translator approach is that it provides for greater control by the network administrator. For exam- ple, since summary reports would be sent by RTP translators rather than by client summarizers, it would be possible for administrators to control the propagation of user information on a site-by-site basis, rather than on a per-session basis. For example, rather than having this sent in the summary report, it could be stored as a temporary attribute in the area directory server. This may be perceived as a substantial advantage by corporations looking to control access to directory information. For those cases where it is desirable to allow external access to area registration information, the IP address of the area directory server may be advertised in the summary report. This allows senders with appropriate privileges to retrieve conference registration data from the area directory server via LDAP. The RTP translator approach has several major disadvantages. These include: Requires modifications to routers Increases loading on routers that now must function as RTP translators 5. Acknowledgements Thanks to Steve Casner of Precept, Mark Handley of ISI, Bob Hinden of Ipsilon and Thomas Pfenning and Stefan Solomon of Microsoft for useful discussions of this problem space. 6. References [1] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. "RTP: A Transport Protocol for Real-Time Applications." RFC 1889, GMD Fokus, January 1996. [2] H. Schulzrinne. "RTP Profile for Audio and Video Conferences with Minimal Control." RFC 1890, GMD Fokus, January 1996. [3] M. F. Speer, S. McCanne. "RTP Usage with Layered Multimedia Streams." draft-speer-avt-layered-video-01.txt, Sun Microsystems, LBNL, June 1996. [4] Y. Yaacovi, M. Wahl, K. Settle, T. Genovese. "Lightweight Direc- tory Access Protocol: Extensions for Dynamic Directory Services." draft-ietf-asid-ldapv3ext-02.txt, Microsoft, Critical Angle, October, 1996. 7. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Aboba [Page 8] INTERNET-DRAFT 26 November 1996 Phone: 206-936-6605 EMail: bernarda@microsoft.com Aboba [Page 9] From rem-conf-request@es.net Tue Nov 26 19:20:12 1996 Received: from terra.Sarnoff.COM by osi-east.es.net with ESnet SMTP (PP); Tue, 26 Nov 1996 16:19:19 -0800 Received: from section05 (spiez.sarnoff.com [130.33.14.125]) by terra.Sarnoff.COM (8.6.12/8.6.12) with ESMTP id TAA23827; Tue, 26 Nov 1996 19:19:11 -0500 From: Sassan Pejhan Received: by section05 (SMI-8.6/SECTION05-Client) id AAA08901; Wed, 27 Nov 1996 00:19:08 GMT Date: Wed, 27 Nov 1996 00:19:08 GMT Message-Id: <199611270019.AAA08901@section05> To: czhu@ibeam.jf.intel.com Subject: Re: draft-ietf-avt-rtp-payload-02.txt Cc: rem-conf@es.net, sassan@terra.Sarnoff.COM X-Sun-Charset: US-ASCII Chad, Thanks for posting your draft on the RTP payload format for H.263. Some comments/questions: > GOB: for H.263, a Group of Blocks (GOB) comprises of k*16 lines, > depending on the picture format (k=1 for QCIF, CIF and sub-QCIF, k=2 > for 4CIF and k=3 for 16CIF). The copy of the ITU draft on h.263 that I have (dated 2 May, 1996) specifies k=4 (not 3) for 16CIF, hence the number of GOB's is 18 for CIF, 4CIF and 16CIF formats. This has an important implication in terms of bits allocated to the Macroblock address (see below, section 5.2), unless I have an old, out-of-date copy of the draft. > MB: a macroblock (MB) relates to four blocks of luminance and the > spatially corresponding two blocks of chrominance. Each block consists > of 8x8 pixels. Just to nitpick: The chrominance blocks are 8x8, the luminance block 16x16. [..] > 4.1 RTP Header usage > > Each RTP packet starts with a fixed RTP header. The following fields of > the RTP fixed header are used for H.263 video stream: > > Marker bit (M bit): The Marker bit of the RTP header is set to 1 > when the current packet carries the end of current frame. 0 otherwise. > > Payload Type (PT): The Payload Type shall specify H.263 video payload > format. > > Timestamp: The RTP Timestamp encodes the sampling instance of the first > video frame contained in the RTP data packet. The RTP timestamp may be > the same on successive packets if a video frame occupies more than one > packet. For H.263 video stream, the RTP timestamp is based on a 90 kHz > clock, the same as that of RTP payload for H.261 stream. Perhaps the sequence number field can also be used? [..] > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |V |F|P|I|SBIT |EBIT | SRC |U|A|S|R |DBQ| TRB | TR | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Your P, I, SRC, U, A and S fields are bits, 13, 9, 6-8, 10, 12 and 11 of the PTYPE field of the picture layer header respectively. If you re-order these fields in the same way as they appear in the PTYPE field, and place them next to each other, then one simply needs to copy the eight (contiguous) bits (6-13) from the PTYPE field straight onto the h263 payload header, which may be faster and simpler. This would require reversing the definition of the I bit (see below): > I: 1 bit. > Set to 1 if current picture is intra-coded. Otherwise 0. Notice this is > opposite to the picture coding type in PTYPE as defined within the H.263 > bitstream [4]. [...] > MBA: 8 bits > The absolute address of the first MB within its GOB, counting from 0. I mentioned earlier that a GOB in 16CIF is 4*16 lines. Therefore, a GOB in 16CIF resolution would have 4*88=352 Macroblocks. Won't you then need 9 bits for the MBA? If so, you could borrow the extra bit from the R (reserved) field of the Mode B header. [...] I also had a general question on the length of header fields. I am aware of the desirability of having headers with lengths that are a multiple of 4 bytes. I am also aware that this convention has been followed for the other video coding standards (RFC's 2029, 2032, 2035 and 2038). In view of the fact that H.263 is geared towards *very* low bit-rate coding, however, perhaps one should allocate bits parsimoniously to the overhead, especially since the overhead can become large (percentage-wise) for S-QCIF and QCIF images. A case in point is the large 19 bits padding (RR field) in the proposed Mode C header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V |F|P|I|SBIT |EBIT | SRC | QUANT | GOBN | MBA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|A|S|R| HMV1 | VMV1 | HMV2 | VMV2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR |DBQ| TRB | TR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > The following fields are defined the same as in Mode A: F, P, SBIT, > EBIT, SRC, I, A, S, U, V, R, TR, DBQ, TRB, and the rest of the fields > are defined the same as in Mode B, except field RR of 19 bits is > reserved and its value must be zero. If RR is reduced to 3 bits, 2 bytes of overhead could be saved. Similarly, if Mode A is split into 2 modes (with and w/o PB frames), the header could be reduced to 2 bytes for the w/o PB frame mode (by eliminating the TR (8 bits), TRB (3), DBQ(2) and R(2) fields -- you'll need to take the extra bit from the V field). Cheers, Sassan From rem-conf-request@es.net Tue Nov 26 19:30:10 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Tue, 26 Nov 1996 16:29:00 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA18434; Tue, 26 Nov 1996 16:28:50 -0800 Date: Tue, 26 Nov 1996 16:28:49 -0800 (PST) From: Stephen Casner To: rem-conf@es.net Subject: IP/UDP/RTP header compression Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII AVT Working Group: I have sent in the following updated draft on IP/UDP/RTP header compression to be posted as an Internet Draft. Changes in this version: - Removed some "issues" text to bring it into the shape of a protocol specification - Put in several cross references to IPv6 header compression to match corresponding changes there - Defined a new delta encoding scheme that's more appropriate for RTP to replace the temporary use of the scheme from RFC 1144. - Moved a couple of fields based on implementation feedback. Your comments would be appreciated. I'd like to discuss on this list and/or at IETF any issues pertaining to this draft, particularly any questions about functionality or areas that are not clear enough to stand as a protocol specification. Based on the consensus from the Montreal meeting, I'd like to get this ready as soon as possible to go to Last Call. -- Steve ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Internet Engineering Task Force Audio/Video Transport Working Group INTERNET-DRAFT S. Casner / Precept Software draft-ietf-avt-crtp-01.txt V. Jacobson / LBNL November 25, 1996 Expires: 5/97 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Abstract This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. In many cases, all three headers can be compressed to 2-4 bytes. Comments are solicited and should be addressed to the working group mailing list rem-conf@es.net and/or the author(s). This draft updates draft-casner-jacobson-crtp-00.txt which was sent to the rem-conf list but was never officially posted as an Internet-Draft due to a mail los- sage that then left it out of date. At the Montreal IETF meeting in June 1996, this proposal was accepted as a work item of the the Audio/Video Transport working group, hence the draft name change. Expires May 1997 [Page 1] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 1. Introduction Since the Real-time Transport Protocol was published as an RFC [1], there has been growing interest in using RTP as one step to achieve interoperability among different implementations of network audio/video applications. However, there is also concern that the 12-byte RTP header is too large an overhead for 20-byte payloads when operating over low speed lines such as dial-up modems at 14.4 or 28.8 kb/s. (Existing applications operating in this environment may use an application- specific protocol with a header of a few bytes that has reduced func- tionality relative to RTP.) Header size may be reduced through compression techniques as has been done with great success for TCP [2]. In this case, compression might be applied to the RTP header alone, on an end-to-end basis, or to the com- bination of IP, UDP and RTP headers on a link-by-link basis. Compress- ing the 40 bytes of combined headers together provides substantially more gain than compressing 12 bytes of RTP header alone because the resulting size is approximately the same (2-4 bytes) in either case. Compressing on a link-by-link basis also provides better performance because the delay and loss rate are lower. Therefore, the method defined here is for combined compression of IP, UDP and RTP headers on a link-by-link basis. This document defines a compression scheme that may be used with IPv4, IPv6 or packets encapsulated with more than one IP header, though the initial focus is on IPv4. It is intended that the IP/UDP/RTP compres- sion defined here will fit within and be referenced by the the more com- plete compression framework [3] specified by Mikael Degermark, et. al., which covers both IPv6 and IPv4 with TCP and non-TCP as two classes of transport above IP. IP/UDP/RTP would be extracted as a third class from the non-TCP class. 2. Assumptions and Tradeoffs The goal of this compression scheme is to reduce the IP/UDP/RTP headers to two bytes for most packets in the case where no UDP checksums are being sent, or four bytes with checksums. It is motivated primarily by the specific problem of sending audio and video over 14.4 and 28.8 dialup modems. These links tend to provide full-duplex communication, so the protocol takes advantage of that fact, though this constraint could be removed. This specification does not address segmentation and preemption of large packets to reduce the delay across the slow link experienced by small real-time packets, except to identify in Section 4 some interactions between segmentation and compression that may occur. Segmentation schemes may be defined separately and used in conjunction with the Expires May 1997 [Page 2] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 compression defined here. It should be noted that implementation simplicity is an important factor to consider in evaluating the a compression scheme. Communications servers may need to support compression over perhaps as many as 100 dial-up modem lines using a single processor. Therefore, it may be appropriate to make some simplifications in the design at the expense of generality, or to produce a flexible design that is general but can be subsetted for simplicity. The next sections discuss some of the trade- offs listed here. 2.1. Simplex vs. Full Duplex In the absence of other constraints, a compression scheme that worked over simplex links would be preferred over one that did not. However, operation over a simplex link requires periodic refreshes with an uncompressed packet header to restore compression state in case of error. If an explicit error signal can be returned instead, the delay to recovery may be shortened substantially. The overhead in the no- error case is also reduced. Some UDP applications may require only sim- plex communication, but RTP applications will frequently require full duplex communication. The application may be 2-way, as in a telephone conversation, but even if data flows in only one direction there is a need for a return path to carry reception feedback in RTCP packets. This specification includes an error indication on the reverse path, however it would be possible to use a periodic refresh instead. When- ever the decompressor detected an error in a particular packet stream, it would simply discard all packets in that stream until an uncompressed header for was received for that stream, and then resume decompression. The penalty would be the potentially large number of packets discarded. 2.2. Segmentation and Layering Delay induced by the time required to send a large packet over the slow link is not a problem for one-way audio, for example, because the receiver can adapt to the variance in delay. However, for interactive conversations, minimizing the end-to-end delay is critical. Segmenta- tion of large, none-real-time packets to allow small real-time packets to be transmitted between segments can reduce the delay. This specification deals only with compression and assumes segmentation, if included, will be handled as a separate layer. It seems inappropri- ate to integrate segmentation and compression in such a way that the compression could not be used by itself in situations where segmentation was deemed unnecessary or impractical. Similarly, one would like to avoid any requirements for a reservation protocol. The compression scheme can be applied locally on the two ends of a link independent of Expires May 1997 [Page 3] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 any other mechanisms except for the requirements that the link layer provide some packet type codes, a packet length indication, and good error detection. Conversely, separately compressing the IP/UDP and RTP layers loses too much of the compression gain that is possible by treating them together. Crossing these protocol layer boundaries is appropriate because the same function is being applied across all layers. 3. The Compression Algorithm The compression algorithm defined in this document draws heavily upon the design of TCP/IP header compression as described in RFC 1144 [2]. Readers are referred to that RFC for more information on the underlying motivations and general principles of header compression. 3.1. The basic idea In TCP header compression, the first factor of two comes from the obser- vation that half of the bytes in the header remain constant over the life of the connection. After sending the uncompressed header once, these fields may be elided from the compressed headers that follow. The remaining compression comes from differential coding on the changing fields to reduce their size, and from eliminating the changing fields entirely for common cases by calculating the changes from the length of the packet. This length is indicated by the link-level protocol. For RTP header compression, some of the same techniques may be applied. However, the big gain comes from the observation that although several fields change in every packet, the difference from packet to packet is often constant and therefore the second-order difference is zero. By maintaining both the uncompressed header and the first-order differences in the session state shared between the compressor and decompressor, all that must be communicated is an indication that the second-order differ- ence was zero. The decompressor can reconstruct the original header without any loss of information. Just as TCP/IP header compression maintains shared state for multiple simultaneous TCP connections, this IP/UDP/RTP compression must maintain state for multiple session contexts. A session context is defined by the combination of the IP source and destination addresses, the UDP source and destination ports, and the RTP SSRC field. Because the RTP compression is lossless, it may be applied to any UDP traffic that benefits from it. Most likely, the only packets that will benefit are RTP packets, but it is acceptable to use heuristics to determine whether or not the packet is an RTP packet because no harm is done if the heurisic gives the wrong answer. This does require Expires May 1997 [Page 4] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 executing the compression algorithm for all UDP packets. Most implemen- tations will need to maintain a negative cache of packet streams (iden- tified by addresses and ports but not the SSRC field) that have failed to compress as RTP packets for some number of attempts. Failing to compress means that the fields that are expected to remain constant most of the time, such as the payload type field, keep changing. Even if the other fields remain constant, a packet stream with a constantly changing SSRC field must be entered in the negative cache to avoid consuming all of the available session contexts. When RTP compression fails, the IP and UDP headers may still be compressed. In order to communicate packets in the various uncompressed and compressed forms, this protocol depends upon the link layer being able to provide an indication of four packet types in addition to the packet types that indicate IPv4 and IPv6: FULL_HEADER - communicates the uncompressed IP header plus any fol- lowing headers and data to establish the uncompressed header state in the decompressor for a particular context. That context is identified by an 8-bit session context ID. In order to carry the context ID without expanding the size of the header, the ID replaces the low byte of the total length field in the IPv4 header or IPv6 base header. (The actual length may be inferred from the length provided by the link layer.) The FULL_HEADER packet type is part of the compression framework defined in [3], which describes compression of protocols other than UDP/RTP and encapsulation by multiple IP headers as indicated by the IPv4 protocol field or the IPv6 next header field. A generation number is carried in the FULL_HEADER for the COMPRESSED_NON_TCP packet type defined in [3]. The 4-bit sequence number defined in Section 3.3 of this document is carried in the Data field of the FULL_HEADER as defined in Sec- tion 5.3.2 and 12 of [3]. COMPRESSED_NON_TCP - communicates the compressed IP and UDP headers as defined in [3] without compressing the IPv4 ID field. This takes one or two bytes more than the COMPRESSED_UDP form listed next, but may be more resilient to packet loss. This packet type can also carry in its Data field the 4-bit sequence number defined in Section 3.3. COMPRESSED_UDP - communicates the IP and UDP headers compressed to 6 or fewer bytes (often 2 if UDP checksums are disabled), followed by any subsequent headers (possibly RTP) in uncompressed form, plus data. This packet type is used when there are differences in the usually constant fields of the (potential) RTP header. It rede- fines the SSRC field of the session context. The format is shown in section 3.4. Expires May 1997 [Page 5] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 COMPRESSED_RTP - indicates that the RTP header is compressed along with the IP and UDP headers. The result may still be just two bytes. This packet type is used when the second-order difference is zero and also to communicate first-order differences as delta encodings. The format is shown in section 3.3. CONTEXT_STATE - indicates a special packet sent from the decompres- sor to the compressor to communicate a list of context IDs for which synchronization has or may have been lost. This packet is only sent across the single link so it requires no IP header. The format is shown in section 3.6. Assignment of numeric codes for these four packet types in the Point- to-Point Protocol [4] will be made by the Internet Assigned Numbers Authority. Section 13 of [3] specifies that the FULL_HEADER packet will share the IPv6 packet type and demultiplex based on the IP version field. 3.2. Header Compression for RTP Data Packets In the IPv4 header, only the total length, packet ID, and header check- sum fields will normally change. The total length is redundant with the length provided by the link layer, and since this compression scheme must depend upon the link layer to provide good error detection (e.g., PPP's CRC), the header checksum may also be elided. This leaves only the packet ID, which, assuming no IP fragmentation, would not need to be communicated. However, in order to maintain lossless compression, changes in the packet ID will be transmitted. In the IPv6 base header, there is no packet ID nor header checksum and only the payload length field changes. In the UDP header, the length field is redundant with the IP total length field and the length indicated by the link layer. The UDP check- sum field will be a constant zero if the source elects not to generate UDP checksums. Otherwise, the checksum must be communicated intact in order to preserve the lossless compression. Maintaining end-to-end error detection for applications that require it is an important princi- ple. In typical usage of the RTP header, the sequence number and the times- tamp will change from packet to packet. If packets are not lost or misordered, the sequence number will increment by one for each packet. For audio packets of constant duration, the timestamp will increment by the number of sample periods conveyed in each packet. For video, the timestamp will change on the first packet of each frame, but then stay constant for any additional packets in the frame. If each video frame occupies only one packet, but the video frames are generated at a con- stant rate, then again the change in the timestamp from frame to frame Expires May 1997 [Page 6] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 is constant. Note that in each of these cases the second-order differ- ence of the sequence number and timestamp fields is often zero. When that's not true, the magnitude of the change is usually much smaller than the full number of bits in the field, so the size can be reduced by encoding the difference rather than the absolute value. The M bit will be set on the first packet of a talkspurt and the last packet of a video frame. If it were treated as a constant field such that each change required sending the full RTP header, this would reduce the compression significantly. Therefore, one bit in the compressed header will carry the M bit explicitly. If the packets are flowing through an RTP mixer, most commonly for audio, then the CSRC list and CC count will also change. However, the CSRC list will typically remain constant during a talkspurt or longer, so it need be sent only when it changes. 3.3. The protocol When the second-order difference of the RTP header is zero, all that need be communicated is a small sequence number to maintain synchroniza- tion and detect packet loss between the compressor and decompressor. Each context has its own separate sequence number space so that a single packet loss need only invalidate one context. To synchronize with the decompressor, the compressor inserts the current value of the sequence number into the Data field of the FULL_HEADER or COMPRESSED_NON_TCP packet whenever one of those is transmitted (see Sections 5.3.2 and 6 of [3]). When the second-order difference of the RTP header is not zero for some fields, the new first-order difference for just those fields is communi- cated using a compact encoding. The new first-order difference updates the uncompressed header in the decompressor's session context, and it is also stored explicitly in the context to be used for updating the field again on subsequent packets in which the second-order difference is zero. In practice, the only fields for which it is useful to store the first- order difference are the IPv4 ID field and the RTP timestamp. For the RTP sequence number field, the usual increment is 1. If the sequence number changes by other than 1, the difference must be communicated but does not set the expected difference for the next packet. Instead, the expected first-order difference remains fixed at 1 so that the differ- ence need not be explictly communicated on the next packet assuming it is in order, For the RTP timestamp, when a FULL_HEADER, COMPRESSED_NON_TCP or COMPRESSED_UDP packet is sent to refresh the state, the stored first- Expires May 1997 [Page 7] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 order difference is initialized to zero. If the timestamp is the same on the next packet (e.g., same video frame), then the second-order difference is zero. Otherwise, the difference between the timestamps of the two packets is transmitted as the new first-order difference. Similarly, since the IPv4 ID field frequently increments by one, the first-order difference for that field is initialized to one when the state is refreshed. Thereafter, whenever the first-order difference changes, it is transmitted and stored in the context. A bit mask will be used to indicate which fields have changed by other than the expected difference. In addition to the small link sequence number, the list of items to be conditionally communicated in the compressed IP/UDP/RTP header is as follows: I = IPv4 packet ID (always 0 if no IPv4 header) U = UDP checksum M = RTP marker bit S = RTP sequence number T = RTP timestamp L = RTP CSRC count and list If 4 bits are needed for the link sequence number to get a reasonable probability of loss detection, there are too few bits remaining to assign one bit to each of these items and still fit them all into a sin- gle byte to go along with the context ID. It is not necessary to explicitly indicate the presence of the UDP checksum because a source will typically include checksums on all pack- ets of a session or none of them. When the session state is initialized with an uncompressed header, if there is a nonzero checksum present, an unencoded 16-bit checksum will be appended to the compressed header in all subsequent packets until this setting is changed by sending another uncompressed packet. Of the remaining items, the CSRC list may be the one least frequently used. Rather than dedicating a bit to indicate CSRC change, an unusual combination of the other bits may be used instead. This bit combination is denoted MSTI. If all four of the bits for the IP packet ID, RTP marker bit, RTP sequence number and RTP timestamp are set, this as a special case indicating an extended form of the compressed RTP header will follow. That header will include an additional byte containing the real values of the four bits plus the CC count. The CSRC list, of length indicated by the CC count, will be included as in the uncompressed header. The following diagram shows the compressed IP/UDP/RTP header with dotted lines indicating fields that are conditionally present. Expires May 1997 [Page 8] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 0 1 2 3 4 5 6 7 +-------------------------------+ | session context | +---+---+---+---+---+---+---+---+ | M | S | T | I | sequence | +---+---+---+---+---+---+---+---+ : : + UDP checksum + (implicit) : : +...............................+ : M'| S'| T'| I'| CC : (if MSTI) +...............................+ : delta IPv4 ID : (if I or I') +...............................+ : delta RTP sequence : (if S or S') +...............................+ : delta RTP timestamp : (if T or T') +...............................+ : : : CSRC list : (if MSTI) : : : : +...............................+ : : : RTP header extension : (if X set in context) : : : : +---+---+---+---+---+---+---+---+ | RTP data | : : The delta fields are encoded with the following variable-length mapping for compactness: A change of zero through 127 is represented directly in one byte. If the most significant two bits of the byte are 10 or 11, this signals an extension to a two- or three-byte value, respectively. The least significant six bits of the first byte are combined, in decreasing order of significance, with the next one or two bytes to form a 14- or 22- bit value. The encoding of decimal values to hex bytes is shown in the following table: Expires May 1997 [Page 9] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 Decimal Hex 0 00 : : 127 7F 128 80 80 : : 16383 BF FF 16384 C0 40 00 : : 4194303 FF FF FF A change in the RTP timestamp value greater than 4194303 forces the RTP header to be sent uncompressed using a FULL_HEADER, COMPRESSED_NON_TCP or COMPRESSED_UDP packet type. The context that must be maintained for each ID is as follows: o The full IP, UDP and RTP headers. Multiple IP headers may be included on encapsulated packets. o The first difference for the IPv4 ID field, initialized to 1. o The first difference for the RTP timestamp field, initialized to 0. o The current 4-bit sequence number. o The current generation number (see [3]). 3.4. Compression of non-RTP UDP Packets If there is a change in any of the fields of the RTP header that are normally constant (such as the payload type field), then an uncompressed RTP header must be sent. This header may be carried in a COMPRESSED_UDP packet rather than a FULL_HEADER packet. The COMPRESSED_UDP packet has the same format as the COMPRESSED_RTP packet except that the M, S and T bits are always 0 and the corresponding fields are not present: Expires May 1997 [Page 10] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 0 1 2 3 4 5 6 7 +-------------------------------+ | session context | +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | I | sequence | +---+---+---+---+---+---+---+---+ : : + UDP checksum + (implicit) : : +...............................+ : delta IPv4 ID : (if I) +---+---+---+---+---+---+---+---+ | UDP data | : (uncompressed RTP header) : Note that this constitutes a form of IP/UDP header compression different >from COMPRESSED_NON_TCP packet type defined in [3]. The motivation is to allow reaching the target of two bytes when UDP checksums are dis- abled, as IPv4 allows. The protocol in [3] does not use differential coding for UDP packets, so in the IPv4 case, two bytes of IP ID, and two bytes of UDP checksum if nonzero, would always be transmitted in addi- tion to two bytes of compression prefix. 3.5. Compression of RTCP Control Packets By relying on the RTP convention that data is carried on an even port number and the corresponding RTCP packets are carried on the next higher (odd) port number, one could tailor separate compression schemes to be applied to RTP and RTCP packets. For RTCP, the compression could apply not only to the header but also the "data", that is, the contents of the different packet types. The numbers in Sender Report (SR) and Receiver Report (RR) RTCP packets would not compress well, but the text informa- tion in the Source Description (SDES) packets could be compressed down to a bit mask indicating each item that was present but compressed out (for timing purposes on the SDES NOTE item and to allow the end system to measure the average RTCP packet size for the interval calculation). However, in the compression scheme defined here, no compression will be done on RTCP packets for several reasons. Since the RTP protocol specification suggests that the RTCP packet interval be scaled so that the aggregate RTCP bandwidth used by all participants in a session will be no more than 5% of the session bandwidth, there is not much to be gained from RTCP compression. Compressing out the SDES items would require a significant increase in the shared state that must be stored for each context ID. And, in order to allow compression when SDES information for several sources was sent through an RTP "mixer", it would be necessary to maintain a separate RTCP session context for each Expires May 1997 [Page 11] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 SSRC identifier. In a session with more than 255 participants, this would cause perfect thrashing of the context cache even when only one participant was sending data. 3.6. Error Recovery Whenever the 4-bit sequence number for a particular context increments by other than 1, except when set by a FULL_HEADER or COMPRESSED_NON_TCP packet, the decompressor must invalidate that context and send a CONTEXT_STATE packet back to the compressor indicating that the context has been invalidated. All packets for the invalid context must be dis- carded until a FULL_HEADER or COMPRESSED_NON_TCP packet is received for that context. When an error occurs on the link, the link layer will usually discard the packet that was damaged (if any), but may provide an indication of the error. Some time may elapse before another packet is delivered for the same context, and then that packet would have to be discarded by the decompressor when it is observed to be out of sequence, resulting in at least two packets lost. To allow faster recovery if the link does pro- vide an explicit error indication, the decompressor may optionally send a CONTEXT_STATE packet listing the last valid sequence number and gen- eration number for one or more recently active contexts. For a given context, if the compressor has sent no compressed packet with a higher sequence number, no corrective action is required. Otherwise, the compressor may mark the context invalid so that the next packet is sent in FULL_HEADER or COMPRESSED_NON_TCP mode. If the generation number does not match the current generation of the COMPRESSED_NON_TCP packet, then the FULL_HEADER must be sent. The format of the CONTEXT_STATE packet is shown in the following diagram. The first byte is a type code to allow the CONTEXT_STATE packet type to be shared for compression of other protocols in the IPv6 scheme [3]. For this IP/UDP/RTP compression scheme, the remainder of the CONTEXT_STATE packet is structured as a list of blocks to allow the state for multiple contexts to be indicated, preceded by a one-byte count of the number of blocks. Expires May 1997 [Page 12] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | compression type = 1 * | +---+---+---+---+---+---+---+---+ | context count | +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | session context | +---+---+---+---+---+---+---+---+ | I | 0 | 0 | 0 | sequence | +---+---+---+---+---+---+---+---+ | 0 | generation | +---+---+---+---+---+---+---+---+ ... +---+---+---+---+---+---+---+---+ | session context | +---+---+---+---+---+---+---+---+ | I | 0 | 0 | 0 | sequence | +---+---+---+---+---+---+---+---+ | 0 | generation | +---+---+---+---+---+---+---+---+ * Other compression types to be defined in [3]. The bit labeled "I" is set to one for contexts that have been marked invalid and require a FULL_HEADER of COMPRESSED_NON_TCP packet to be transmitted. If the I bit is zero, the context state is advisory. Since the CONTEXT_STATE packet itself may be lost, retransmission of one or more blocks is allowed. It is expected that retransmission will be triggered only by receipt of another packet, but if the line is near idle, retransmission might be triggered by a relatively long timer (on the order of 1 second). If a CONTEXT_STATE block for a given context is retransmitted, it may cross paths with the FULL_HEADER or COMPRESSED_NON_TCP packet intended to refresh that context. In that case, the compressor may choose to ignore the error indication. In the case where UDP checksums are being transmitted, the decompressor could attempt to use the "twice" algorithm described in section 10.1 of [3]. In this algorithm, the delta is applied more than once on the assumption that the delta may have been the same on the missing packet(s) and the one subsequently received. For the scheme defined here, the difference in the 4-bit sequence number tells number of times the delta must be applied. Note, however, that there is a nontrivial risk of an incorrect positive indication. It may be advisable to Expires May 1997 [Page 13] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 request a FULL_HEADER or COMPRESSED_NON_TCP packet even if the "twice" algorithm succeeds. Some errors may not be detected, for example if 16 packets are lost in a row and the link level does not provide an error indication. In that case, the decompressor will generate packets that are not valid. If UDP checksums are being transmitted, the receiver will probably detect the invalid packets and discard them, but the receiver does not have any means to signal the decompressor. Therefore, it is recommended that the decompressor verify the UDP checksum periodically, perhaps one out of 16 packets. If an error is detected, the decompressor would invalidate the context and signal the compressor with a CONTEXT_STATE packet. 4. Interaction With Segmentation A segmentation scheme may be used in conjunction with RTP header compression to allow small, real-time packets to interrupt large, presumably non-real-time packets in order to reduce delay. It is assumed that the large packets bypass the compressor and decompressor since the interleaving would modify the sequencing of packets at the decompressor and cause the appearance of errors. Header compression should be less important for large packets since the overhead ratio is smaller. If some packets from an RTP session context are selected for segmenta- tion (perhaps based on size) and some are not, there is a possibility of re-ordering. This would reduce the compression efficiency because the large packets would appear as lost packets in the sequence space. How- ever, this should not cause more serious problems because the RTP sequence numbers should be reconstructed correctly and will allow the application to correct the ordering. Link errors detected by the segmentation scheme using its own sequencing information may be indicated to the compressor with an advisory CONTEXT_STATE message just as for link errors detected by the link layer itself. The context ID byte is placed first in the COMPRESSED_RTP header so that this byte may be shared with the segmentation layer if such sharing is feasible and has been negotiated. Since the context ID may have any value, it can be set to match context information from the segmentation layer. 5. Negotiating Compression The use of IP/UDP/RTP compression over a particular link is a function of the link-layer protocol. It is expected that such negotiation will be defined separately for PPP [4], for example. Expires May 1997 [Page 14] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 6. Acknowledgments Several people have contributed to the design of this compression scheme and related problems. Scott Petrack initiated discussion of RTP header compression in the AVT working group at Los Angeles in March, 1996. Carsten Bormann has developed an overall achitecture for compression in combination with traffic control across a low-speed link, and made several specific contributions to the scheme described here. David Oran independently developed a note based on similar ideas, and suggested the use of PPP Multilink protocol for segmentation. Mikael Degermark has contributed advice on integration of this compression scheme with the IPv6 compression framework. 7. References: [1] H. Shulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for real-time applications," RFC 1889. [2] V. Jacobson, "TCP/IP Compression for Low-Speed Serial Links," RFC 1144. [3] M. Degermark, B. Nordgren, and S. Pink, "Header Compression for IPv6," work in progress. [4] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1548. 8. Security Considerations Because encryption eliminates the redundancy that this compression scheme tries to exploit, there is some inducement to forgo encryption in order to achieve operation over a low-bandwidth link. However, for those cases where encryption of data and not headers is satisfactory, RTP does specify an alternative encryption method indicated by different payload types. 9. Authors' Addresses Stephen L. Casner Precept Software, Inc. 1072 Arastradero Road Palo Alto, CA 94304 United States EMail: casner@precept.com Van Jacobson MS 46a-1121 Expires May 1997 [Page 15] Internet Draft draft-ietf-avt-crtp-01.txt November 1996 Lawrence Berkeley National Laboratory Berkeley, CA 94720 United States EMail: van@ee.lbl.gov Expires May 1997 [Page 16] From rem-conf-request@es.net Tue Nov 26 23:37:56 1996 Received: from proxy1.ba.best.com by osi-east.es.net with ESnet SMTP (PP); Tue, 26 Nov 1996 20:36:48 -0800 Received: from mg131-119.ricochet.net (mg131-119.ricochet.net [204.179.131.119]) by proxy1.ba.best.com (8.8.3/8.8.3) with SMTP id UAA14948; Tue, 26 Nov 1996 20:34:04 -0800 (PST) Date: Tue, 26 Nov 1996 20:34:04 -0800 (PST) Message-Id: <1.5.4.16.19961126212430.08bf6556@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: Bernard Aboba From: Ross Finlayson Subject: Re: Summary of RTP scalability discussions Cc: rem-conf@es.net > 4.6. Use of TTL scoping and summary messages > > In this approach, RTCP receiver reports would be sent with a TTL of 1, > and a designated summarizer would be elected to provide summary > reports with a larger TTL. This approach has the advantage of increas- > ing the leverage of those RTCP receiver reports that are sent, and is > likely to be particularly effective for conferences in which member- > ship is densely distributed. However, in sparsely distributed confer- > ences, the effect of summarization will be small unless multiple lev- > els of summarization are used. The designated summarizer would not > necesarily be a router; it could also be another receiver, although > this brings up the possibility of how a new summarizer could be > elected if the current summarizer leaves the conference. Bernard, I'm glad to see someone following up on this idea. When I mentioned it a few days ago I hadn't really fleshed it out much. However, one thing I had in mind - a bit different from what you suggest - is that *every* (leaf) node would act as both a regular reporter *and* a summarizer. That is, in this approach each node would send out 'raw' reports with frequency f_raw to the entire session TTL - just as it does now. However, each node would also send out 'summary' reports with frequency f_summary (> f_raw) to some smaller TTL (not necessarily 1, BTW). You could also imagine this scheme being hierarchical - i.e., with 2nd-level summaries, etc. An advantage of this approach (every leaf node being a summarizer) is that you don't have to worry about electing summarizers. Of course, "the devil is in the details" - specifically: What would the TTLs (raw & summary) be, along with the corresponding frequencies (f_raw, f_summary), and how would they be chosen (perhaps dynamically, based on the frequency of incoming reports?)? Ross. From rem-conf-request@es.net Wed Nov 27 02:36:05 1996 Received: from hofmann.CS.Berkeley.EDU by osi-east.es.net with ESnet SMTP (PP); Tue, 26 Nov 1996 23:35:24 -0800 Received: from internaut.com (Cust108.Max16.Seattle.WA.MS.UU.NET [153.34.42.236]) by hofmann.CS.Berkeley.EDU (8.6.11/8.6.6.Beta11) with SMTP id XAA10990; Tue, 26 Nov 1996 23:35:21 -0800 Received: from [204.57.137.9] by internaut.com (NX5.67c/NeXT-3.0) id AA23588; Tue, 26 Nov 96 23:29:17 -0800 Message-Id: <9611270729.AA23588@internaut.com> From: Bernard Aboba To: Ross Finlayson Cc: rem-conf Subject: Re: Summary of RTP scalability discussions Date: Tue, 26 Nov 1996 23:32:54 -0800 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > I'm glad to see someone following up on this idea. When I mentioned it a > few days ago I hadn't really fleshed it out much. However, one thing I had > in mind - a bit different from what you suggest - is that *every* (leaf) > node would act as both a regular reporter *and* a summarizer. Will they summarize just for themselves or for other nodes as well? If just for themselves, is the idea to decrease total bandwidth by reporting less often? Taken to the extreme, we could provide a session summary in the RTCP BYE message. However, we need to be careful not to worsen the convergence time by not providing enough info for the population estimate. >That is, in > this approach each node would send out 'raw' reports with frequency f_raw to > the entire session TTL - just as it does now. However, each node would > also send out 'summary' reports with frequency f_summary (> f_raw) to some > smaller TTL (not necessarily 1, BTW). You could also imagine this scheme > being hierarchical - i.e., with 2nd-level summaries, etc. I guess I don't understand why you'd send the "raw" reports with global scope, while sending the summaries with local scope. Don't you want it the other way around? Sending the "raw" reports with local scope would allow receivers to converge quickly on a local population estimate, and would provide timely updates for the "summary" reports which would be sent with global scope on a less frequent basis. However, since the "summary" reports would be for more than one receiver, this should result in more rapid convergence on the population estimate for the same level of RTCP bandwidth usage. > > An advantage of this approach (every leaf node being a summarizer) is that > you don't have to worry about electing summarizers. > > Of course, "the devil is in the details" - specifically: What would the TTLs > (raw & summary) be, along with the corresponding frequencies (f_raw, > f_summary), and how would they be chosen (perhaps dynamically, based on the > frequency of incoming reports?)? > > Ross. > From rem-conf-request@es.net Wed Nov 27 04:10:01 1996 Received: from proxy1.ba.best.com by osi-east.es.net with ESnet SMTP (PP); Wed, 27 Nov 1996 01:09:01 -0800 Received: from kaipara.live.com (kaipara.live.com [206.86.37.12]) by proxy1.ba.best.com (8.8.3/8.8.3) with SMTP id BAA29486; Wed, 27 Nov 1996 01:06:48 -0800 (PST) Date: Wed, 27 Nov 1996 01:06:48 -0800 (PST) Message-Id: <1.5.4.16.19961127015711.08bf3858@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: Bernard Aboba From: Ross Finlayson Subject: Re: Summary of RTP scalability discussions Cc: rem-conf >>... *every* (leaf) >> node would act as both a regular reporter *and* a summarizer. > >Will they summarize just for themselves or for other nodes as well? I was originally imagining that when a node sends out a summary report, it would do so based on all the information it had recently gotten in 'raw' reports from its (lower-TTL) peers. But I can also imagine nodes summarizing "just for themselves". >I guess I don't understand why you'd send the "raw" reports with global >scope, >while sending the summaries with local scope. Don't you want it the other >way around? Oops, you're right - what I said in my last message was backwards. I meant it the other way round: Each node would send its raw reports to a *low* TTL, and (less often) send summaries to a *higher* TTL (perhaps the entire session TTL, for a 2-level hierarchy). Sorry about that... Ross. From rem-conf-request@es.net Wed Nov 27 09:10:43 1996 Received: from tamdhu (actually tamdhu.dcs.st-and.ac.uk) by osi-east.es.net with ESnet SMTP (PP); Wed, 27 Nov 1996 06:09:34 -0800 Received: from dcs.st-andrews.ac.uk (bushmills.dcs.st-and.ac.uk) by tamdhu (4.1/SMI-4.1) id AA10591; Wed, 27 Nov 96 14:08:32 GMT Message-Id: <9611271408.AA10591@tamdhu> To: Ross Finlayson Cc: rem-conf@es.net Subject: Re: Summary of RTP scalability discussions In-Reply-To: Your message of "Wed, 27 Nov 1996 01:06:48 PST." <1.5.4.16.19961127015711.08bf3858@pop.best.com> Date: Wed, 27 Nov 1996 14:08:04 +0000 From: Paul Harrington Ross> I was originally imagining that when a node sends out a summary Ross> report, it would do so based on all the information it had Ross> recently gotten in 'raw' reports from its (lower-TTL) peers. Ross> But I can also imagine nodes summarizing "just for themselves". I implemented something like this for monitoring workstation loads http://warp.dcs.st-and.ac.uk/warp/reports.html#W1-96 but did not like the fact that summaries were distributed back along the same tree that generated the data from which the summaries were made. However, just simply lumping several messages together at a concentrator, the messages per second rate can be dramatically reduced. Sending a simple statistical summary of the data is space efficient and was adequate for our purposes. Although unimplemented, I don't see too much difficulty in enabling any node to be a summariser, esp if you have it rate-limited: each node would start a timer to trigger sending a summary, the timer being reset if a summary is heard >from elsewhere before it fires. There was a talk at OSDI by .. David Tennenhouse from MIT on active networks http://www.tns.lcs.mit.edu/activeware/ which seems an elegant way to solve a lot of these problems: run some appication specific code on the routers themselves! pjjH From rem-conf-request@es.net Wed Nov 27 12:57:09 1996 Received: from rsung.crn.cogs.susx.ac.uk by osi-east.es.net with ESnet SMTP (PP); Wed, 27 Nov 1996 09:56:33 -0800 Received: by rsung.crn.cogs.susx.ac.uk (Smail3.1.29.1 #3) id m0vSoEv-0003yAC; Wed, 27 Nov 96 17:57 GMT Message-Id: Date: Wed, 27 Nov 96 17:57 GMT From: Ian Wakeman To: rem-conf@es.net Subject: Re: Summary of RTP scalability discussions In-Reply-To: <9611271408.AA10591@tamdhu> References: <1.5.4.16.19961127015711.08bf3858@pop.best.com> <9611271408.AA10591@tamdhu> With respect to the RTP report summaries, and scalable techniques for getting hold of them - can I point people at the work I did on scalable congestion control that was published with Thierry Turletti and Jean Bolot in Sigcomm94? It had a scalable sender polling technique that elicited random responses and gave reasonable estimates of receiver groups within tens of rtts. In addition, I have some unfinished work from about a year and a half ago on automatic configuration of server hierarchies in multicast networks, intended as a starting point for automatic key distribution and for those using the logging approach out of Stanford for reliable multicast. Essentially its an analysis of increasing scoped TTL searches to graft on and create the appropriate number of levels in the hierarchy. If anyone's interested, I'll dig it out and pass it over (since I haven't found time in the last year and a bit to do anything with it...). cheers ian From rem-conf-request@es.net Wed Nov 27 13:40:03 1996 Received: from ormail.intel.com by osi-east.es.net with ESnet SMTP (PP); Wed, 27 Nov 1996 10:38:31 -0800 Received: from ibeam.intel.com (ibeam.jf.intel.com [134.134.208.3]) by ormail.intel.com (8.8.3/8.7.3) with SMTP id KAA01706; Wed, 27 Nov 1996 10:38:20 -0800 (PST) Received: from DUALPRO by ibeam.intel.com with smtp (Smail3.1.28.1 #6) id m0vSotl-000RzPC; Wed, 27 Nov 96 10:39 PST Received: by DUALPRO with Microsoft Mail id <01BBDC4E.D3ECEC60@DUALPRO>; Wed, 27 Nov 1996 10:36:20 -0800 Message-ID: <01BBDC4E.D3ECEC60@DUALPRO> From: Chunrong Chad Zhu To: "czhu@ibeam.jf.intel.com" , 'Sassan Pejhan' Cc: "rem-conf@es.net" , "sassan@terra.Sarnoff.COM" Subject: RE: draft-ietf-avt-rtp-payload-02.txt Date: Wed, 27 Nov 1996 10:36:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sassan, Thanks for the comments and suggestions. I would seriously consider to = increase MBA to 9 bits using R in the next revision. In the mean time, I = would also consider your other suggestions too. But I do have some = reasons to oppose some other changes you suggested. Please see my = comments below. --Chad > GOB: for H.263, a Group of Blocks (GOB) comprises of k*16 lines,=20 > depending on the picture format (k=3D1 for QCIF, CIF and sub-QCIF, = k=3D2=20 > for 4CIF and k=3D3 for 16CIF). The copy of the ITU draft on h.263 that I have (dated 2 May, 1996) specifies k=3D4 (not 3) for 16CIF, hence the number of GOB's is 18 for CIF, 4CIF and 16CIF formats. This has an important implication in=20 terms of bits allocated to the Macroblock address (see below, section = 5.2), unless I have an old, out-of-date copy of the draft. My mistake, k=3D4 for 16CIF. > MB: a macroblock (MB) relates to four blocks of luminance and the=20 > spatially corresponding two blocks of chrominance. Each block consists = > of 8x8 pixels. Just to nitpick: The chrominance blocks are 8x8, the luminance block = 16x16. I was refering to "block", 16x16 luminance pixels are considered as four = luminace blocks. Please refer to H.263 spec section 4.2.1: "A macroblock = relates to 16 pixels by 16 lines of Y and the spatially corresponding 8 = pixels by 8 lines of Cb and Cr. Further, a macroblock consists of four = luminance blocks and the two spatially corresponding colour diffenerce = blocks as shown in figure 5...); =20 Perhaps the sequence number field can also be used? It is assumed. Your P, I, SRC, U, A and S fields are bits, 13, 9, 6-8, 10, 12 and 11 of the PTYPE field of the picture layer header respectively. If you re-order these fields in the same way as they appear in the PTYPE field, and place them next to each other, then one simply needs to copy the eight (contiguous) bits (6-13) from the PTYPE field straight onto the=20 h263 payload header, which may be faster and simpler. This would require reversing the definition of the I bit (see below): This sounds interesting, but reorder them would not simply result in a = "copy" of byte. This is because these 8 bits are not byte aligned. So it still require shifting bits. I = was trying to keep P close to F bit, since the two together decides mode. I mentioned earlier that a GOB in 16CIF is 4*16 lines. Therefore, a GOB in 16CIF resolution would have 4*88=3D352 Macroblocks. Won't you then need 9 bits for the MBA? If so, you could borrow the extra bit from the R (reserved) field of the Mode B header. This is sound. Let me try to shuffle the bits and use R to increase MBA = to 9 bits in both Mode B and C. I also had a general question on the length of header fields. I am aware of the desirability of having headers with lengths that are a multiple of 4 bytes. I am also aware that this convention has been followed for=20 the other video coding standards (RFC's 2029, 2032, 2035 and 2038). In view of the fact that H.263 is geared towards *very* low bit-rate coding, however, perhaps one should allocate bits parsimoniously to the overhead, especially since the overhead can become large (percentage-wise) for S-QCIF and QCIF images.=20 A case in point is the large 19 bits padding (RR field) in the proposed=20 Mode C header: If RR is reduced to 3 bits, 2 bytes of overhead could be saved. Similarly, if Mode A is split into 2 modes (with and w/o PB frames), the header could be reduced to 2 bytes for the w/o PB frame mode=20 (by eliminating the TR (8 bits), TRB (3), DBQ(2) and R(2) fields -- you'll need to take the extra bit from the V field). First of all, Mode B and C are intended for cases where a GOB could not = fit in a packet, which is unlikely in very low bit rate. Mode A is = expected to be used at low rates, and most commonly. We would want to = make it as simple as possible to speed up common cases. =20 As RR in mode C, I am not convinced the saving of 16 bits is significant = and worth breaking 4 bytes alignment,=20 because Mode C packets would be very rare even at hight data rates = according to our experiments. So, keeping the header 4 bytes aligned does not really introduce too = much overhead comparing to the over all size of packet. In current development of H.263+, other modes are being added to base = H.263. We also initialed "slice" strucuture which will reduce the need = for Mode B and C in the future.=20 ---------- From: Sassan Pejhan Sent: Tuesday, November 26, 1996 4:19 PM To: czhu@ibeam.jf.intel.com Cc: rem-conf@es.net; sassan@terra.Sarnoff.COM Subject: Re: draft-ietf-avt-rtp-payload-02.txt Chad, Thanks for posting your draft on the RTP payload format for H.263.=20 Some comments/questions: > GOB: for H.263, a Group of Blocks (GOB) comprises of k*16 lines,=20 > depending on the picture format (k=3D1 for QCIF, CIF and sub-QCIF, = k=3D2=20 > for 4CIF and k=3D3 for 16CIF). The copy of the ITU draft on h.263 that I have (dated 2 May, 1996) specifies k=3D4 (not 3) for 16CIF, hence the number of GOB's is 18 for CIF, 4CIF and 16CIF formats. This has an important implication in=20 terms of bits allocated to the Macroblock address (see below, section = 5.2), unless I have an old, out-of-date copy of the draft. > MB: a macroblock (MB) relates to four blocks of luminance and the=20 > spatially corresponding two blocks of chrominance. Each block consists = > of 8x8 pixels. Just to nitpick: The chrominance blocks are 8x8, the luminance block = 16x16. [..] > 4.1 RTP Header usage > > Each RTP packet starts with a fixed RTP header. The following fields = of=20 > the RTP fixed header are used for H.263 video stream: > > Marker bit (M bit): The Marker bit of the RTP header is set to 1=20 > when the current packet carries the end of current frame. 0 otherwise. >=20 > Payload Type (PT): The Payload Type shall specify H.263 video payload=20 > format. >=20 > Timestamp: The RTP Timestamp encodes the sampling instance of the = first=20 > video frame contained in the RTP data packet. The RTP timestamp may be = > the same on successive packets if a video frame occupies more than = one=20 > packet. For H.263 video stream, the RTP timestamp is based on a 90 kHz = > clock, the same as that of RTP payload for H.261 stream.=20 Perhaps the sequence number field can also be used? [..] > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |V |F|P|I|SBIT |EBIT | SRC |U|A|S|R |DBQ| TRB | TR | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Your P, I, SRC, U, A and S fields are bits, 13, 9, 6-8, 10, 12 and 11 of the PTYPE field of the picture layer header respectively. If you re-order these fields in the same way as they appear in the PTYPE field, and place them next to each other, then one simply needs to copy the eight (contiguous) bits (6-13) from the PTYPE field straight onto the=20 h263 payload header, which may be faster and simpler. This would require reversing the definition of the I bit (see below): > I: 1 bit.=20 > Set to 1 if current picture is intra-coded. Otherwise 0. Notice this = is=20 > opposite to the picture coding type in PTYPE as defined within the = H.263 > bitstream [4]. [...] > MBA: 8 bits > The absolute address of the first MB within its GOB, counting from 0. I mentioned earlier that a GOB in 16CIF is 4*16 lines. Therefore, a GOB in 16CIF resolution would have 4*88=3D352 Macroblocks. Won't you then need 9 bits for the MBA? If so, you could borrow the extra bit from the R (reserved) field of the Mode B header. [...] I also had a general question on the length of header fields. I am aware of the desirability of having headers with lengths that are a multiple of 4 bytes. I am also aware that this convention has been followed for=20 the other video coding standards (RFC's 2029, 2032, 2035 and 2038). In view of the fact that H.263 is geared towards *very* low bit-rate coding, however, perhaps one should allocate bits parsimoniously to the overhead, especially since the overhead can become large (percentage-wise) for S-QCIF and QCIF images.=20 A case in point is the large 19 bits padding (RR field) in the proposed=20 Mode C header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V |F|P|I|SBIT |EBIT | SRC | QUANT | GOBN | MBA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|A|S|R| HMV1 | VMV1 | HMV2 | VMV2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR |DBQ| TRB | TR |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > The following fields are defined the same as in Mode A: F, P, SBIT,=20 > EBIT, SRC, I, A, S, U, V, R, TR, DBQ, TRB, and the rest of the fields=20 > are defined the same as in Mode B, except field RR of 19 bits is=20 > reserved and its value must be zero. If RR is reduced to 3 bits, 2 bytes of overhead could be saved. Similarly, if Mode A is split into 2 modes (with and w/o PB frames), the header could be reduced to 2 bytes for the w/o PB frame mode=20 (by eliminating the TR (8 bits), TRB (3), DBQ(2) and R(2) fields -- you'll need to take the extra bit from the V field). Cheers, Sassan =20 From rem-conf-request@es.net Wed Nov 27 13:49:49 1996 Received: from msri.msri.org (actually msri.org) by osi-east.es.net with ESnet SMTP (PP); Wed, 27 Nov 1996 10:48:44 -0800 Received: (from smap@localhost) by msri.msri.org (8.8.2/8.7.2) id KAA24126 for ; Wed, 27 Nov 1996 10:48:48 -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 sma024115; Wed Nov 27 10:48:43 1996 Received: by hille.msri.org (8.7/MSRI) id KAA19470; Wed, 27 Nov 1996 10:58:28 -0800 (PST) Date: Wed, 27 Nov 1996 10:58:28 -0800 (PST) Message-Id: <199611271858.KAA19470@hille.msri.org> From: joe Reply-to: joe@msri.org Subject: Tamara Munzner on "Visualizing the Structure of the MBone on the Globe and the Web in 3D Hyperbolic Space" MBone Broadcast Announcement ---------------------------- Title: Tamara Munzner on "Visualizing the Structure of the MBone on the Globe and the Web in 3D Hyperbolic Space" Date: Dec 17, 1996 Time: 14:00 PST8PDT 1 hours Contact: joe@msri.org URL: http://www.msri.org/sched/empennage/munzner.html Description: Tamara Munzner speaks in the MSRI Empennage seminar. Form her abstract, follow the link at the left. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Wed Nov 27 15:10:13 1996 Received: from hofmann.CS.Berkeley.EDU by osi-east.es.net with ESnet SMTP (PP); Wed, 27 Nov 1996 12:09:20 -0800 Received: from internaut.com (Cust108.Max16.Seattle.WA.MS.UU.NET [153.34.42.236]) by hofmann.CS.Berkeley.EDU (8.6.11/8.6.6.Beta11) with SMTP id MAA16823; Wed, 27 Nov 1996 12:09:14 -0800 Received: from [204.57.137.9] by internaut.com (NX5.67c/NeXT-3.0) id AA24805; Wed, 27 Nov 96 08:15:18 -0800 Received: by multi with Microsoft Mail id <01BBDC3B.A3697800@multi>; Wed, 27 Nov 1996 08:18:58 -0800 Message-Id: <01BBDC3B.A3697800@multi> From: Bernard Aboba To: Bernard Aboba , 'Ross Finlayson' Cc: "rem-conf@es.net" Subject: RE: Summary of RTP scalability discussions Date: Wed, 27 Nov 1996 08:18:57 -0800 Encoding: 27 TEXT Ross Finlayson said: >I was originally imagining that when a node sends out a summary report, it >would do so based on all the information it had recently gotten in 'raw' >reports from its (lower-TTL) peers. But I can also imagine nodes >summarizing "just for themselves". >Oops, you're right - what I said in my last message was backwards. I meant >it the other way round: Each node would send its raw reports to a *low* >TTL, and (less often) send summaries to a *higher* TTL (perhaps the entire >session TTL, for a 2-level hierarchy). Sorry about that. One of the issues with summarization is the denseness of conference participation. In a sparsely distributed conference, there are unlikely to be more than one or two conference participants on a network, so that summarization has to have more than one level to contribute to a traffic reduction. In a sparsely distributed situation, it matters little if you have a summarizer election or if everyone sends a summary, just so long as these summaries are eventually combined into a (single) higher level summary. In a densely distributed conference, choosing a summarizer will result in a traffic reduction. Question: If more than one summary issues from a network, how do higher level summarizers figure out which summary to listen to? Also, how do they know that they are from the same network unless the summary report includes a subnet mask? From rem-conf-request@es.net Wed Nov 27 16:26:52 1996 Received: from hera.rbi.informatik.uni-frankfurt.de by osi-east.es.net with ESnet SMTP (PP); Wed, 27 Nov 1996 13:24:39 -0800 Received: from dbis.informatik.uni-frankfurt.de (roma.dbis.informatik.uni-frankfurt.de) by hera.rbi.informatik.uni-frankfurt.de with SMTP (1.40.112.4/16.2) id AA272799453; Wed, 27 Nov 1996 22:17:33 +0100 Received: from hera.rbi.informatik.uni-frankfurt.de by dbis.informatik.uni-frankfurt.de with smtp (Smail3.1.28.1 #4) id m0vSrMK-000BmsC; Wed, 27 Nov 96 22:17 MET Received: by hera.rbi.informatik.uni-frankfurt.de (1.40.112.4/16.2) id AA272769452; Wed, 27 Nov 1996 22:17:32 +0100 From: "Prof." Zicari Posted-Date: Wed, 27 Nov 1996 22:17:32 +0100 Received-Date: Wed, 27 Nov 1996 22:17:32 +0100 Message-Id: <199611272117.AA272769452@hera.rbi.informatik.uni-frankfurt.de> Subject: Comdex Internet To: int.net@dbis.informatik.uni-frankfurt.de Date: Wed, 27 Nov 1996 22:17:32 +0100 (MET) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 4869 (apologizes in case if this has been sent twice) Please distribute it, as you see proper. Regards Roberto Zicari Program Chair ----------------------cut here---------------------------------- A Global Player comes to Germany: Object World Frankfurt '97 Team Up with COMDEX Internet Frankfurt/Main - November 27, 1996. A global player will enter the German IT trade show-market in 1997: SOFTBANK COMDEX Inc. - producer of the series of COMDEX trade shows world wide - will launch COMDEX Internet '97 in Frankfurt/Main together with Object World Frankfurt '97. COMDEX Internet '97 and Object World Frankfurt '97 will take place on October 7 - 10, 1997 in the Sheraton Conference Center Frankfurt (Airport), Frankfurt/Main, Germany. The show will consist of two conferences side by side and one combined exposition. COMDEX Internet '97 will be the premiere COMDEX event in Germany, and will focus on the business use of the Internet. The COMDEX Internet'97 conference will cover topics such as: the Internet as a business communication vehicle, Electronic Commerce, Developing Intranet-based applications, and Java. The Object World Frankfurt '97 conference - now in its sixth year - will cover the practical aspects of applying object technology for business, with particular focus on Finance, Telecom, Healthcare and Manufacturing. Object World Frankfurt has experienced constant growth (1996: 60% larger than 1995) and it is recognized as the most important event for Object Technology in Europe. The combined exposition will consist of three dedicated technology areas: a COMDEX Internet Pavilion, an Object World Pavilion and an Open Systems Pavilion. The exposition has been designed to meet the visitors' expectations for Internet and Object Technology products on multi-vendors, and multi-platform systems as indicated by an independent study conducted by META Group on 139 of the 2,800 visitors of this year's Object World Frankfurt '96. The study indicated that: 72 % of attendees operate on Network Operating Systems 69% of attendees operate on UNIX platforms 64% of attendees operate on Windows Desktops 49% of attendees use object technology for Internet/Web application development. COMDEX Internet '97 and Object World Frankfurt '97 are sponsored and organized by Object World Corp. (a subsidiary of SOFTBANK COMDEX Inc.), Object Management Group and LogOn Technology Transfer GmbH. Information on Conferences and Exhibition: Christiane Sattler LogOn Technology Transfer GmbH Burgweg 14, D-61476 Kronberg/Ts., Germany phone: +49-6173-9558-53 fax: +49-6173-9404-20 e-mail: LogOn@omg.org Web: http://www.ltt.de Press Contact: Birgit Osterholt // Annegret Claushues LogOn Technology Transfer GmbH Burgweg 14, D-61476 Kronberg / Ts., Germany phone: +49-6173-9558-56//9558-55 fax: +49-6173-9404-20 e-mail: 101510.3135@compuserve.com (Osterholt) 101354.1424@compuserve.com (Claushues) Web: http://www.ltt.de Background Information: As of May 3, 1996, the Object World Series has been acquired by the producers of the most successful IT trade events worldwide, SOFTBANK COMDEX. This investment reflects a strategic initiative to join with Object Management Group in a move toward the expansion and commercialization of object technology around the world. Object World is the industry's most important event developed to focus on the commercial and practical aspects of applying object technology and provides an ideal forum for business and technical professionals to experience first hand the real-time practice of object technology standards. SOFTBANK COMDEX Inc. Since the introduction of the first COMDEX event in 1979, SOFTBANK COMDEX has continued to meet the growing needs of the global information technology marketplace. COMDEX/Fall, first held in Las Vegas in 1979, is now the largest trade show in North America. In 1996 and 1997 SOFTBANK COMDEX will produce over 40 information technology events in North America, South America, Europe and Asia, which are expected to include over 7,000 exhibiting companies and attract more than one million attendees from over 120 countries. Web: http://www.comdex.com LogOn Technology Transfer GmbH LogOn Technology Transfer GmbH, founded in 1991, is a privately owned company exclusively focused on the Internet and object technology markets. LogOn is organized into five operating divisions: Trade Shows, Marketing, PR, Training and Business. LogOn organizes Object World Frankfurt since 1993. LogOn is the official representative of the Object Management Group (OMG) for Austria, Benelux, France, Germany, Italy, Scandinavia and Switzerland. OMG is the largest software consortium worldwide with more than 700 company members dedicated to promoting the theory and practice of object technology (OT) for the development of distributed computing systems. Web: http://www.ltt.de From rem-conf-request@es.net Wed Nov 27 16:30:08 1996 Received: from hera.rbi.informatik.uni-frankfurt.de by osi-east.es.net with ESnet SMTP (PP); Wed, 27 Nov 1996 13:28:01 -0800 Received: from dbis.informatik.uni-frankfurt.de (roma.dbis.informatik.uni-frankfurt.de) by hera.rbi.informatik.uni-frankfurt.de with SMTP (1.40.112.4/16.2) id AA272229377; Wed, 27 Nov 1996 22:16:17 +0100 Received: from hera.rbi.informatik.uni-frankfurt.de by dbis.informatik.uni-frankfurt.de with smtp (Smail3.1.28.1 #4) id m0vSrL5-000BmsC; Wed, 27 Nov 96 22:16 MET Received: by hera.rbi.informatik.uni-frankfurt.de (1.40.112.4/16.2) id AA272199376; Wed, 27 Nov 1996 22:16:16 +0100 From: "Prof." Zicari Posted-Date: Wed, 27 Nov 1996 22:16:16 +0100 Received-Date: Wed, 27 Nov 1996 22:16:16 +0100 Message-Id: <199611272116.AA272199376@hera.rbi.informatik.uni-frankfurt.de> Subject: Comdex Internet To: int.net@dbis.informatik.uni-frankfurt.de Date: Wed, 27 Nov 1996 22:16:15 +0100 (MET) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 4818 Please distribute it, as you see proper. Regards Roberto Zicari Program Chair ----------------------cut here---------------------------------- A Global Player comes to Germany: Object World Frankfurt '97 Team Up with COMDEX Internet Frankfurt/Main - November 27, 1996. A global player will enter the German IT trade show-market in 1997: SOFTBANK COMDEX Inc. - producer of the series of COMDEX trade shows world wide - will launch COMDEX Internet '97 in Frankfurt/Main together with Object World Frankfurt '97. COMDEX Internet '97 and Object World Frankfurt '97 will take place on October 7 - 10, 1997 in the Sheraton Conference Center Frankfurt (Airport), Frankfurt/Main, Germany. The show will consist of two conferences side by side and one combined exposition. COMDEX Internet '97 will be the premiere COMDEX event in Germany, and will focus on the business use of the Internet. The COMDEX Internet'97 conference will cover topics such as: the Internet as a business communication vehicle, Electronic Commerce, Developing Intranet-based applications, and Java. The Object World Frankfurt '97 conference - now in its sixth year - will cover the practical aspects of applying object technology for business, with particular focus on Finance, Telecom, Healthcare and Manufacturing. Object World Frankfurt has experienced constant growth (1996: 60% larger than 1995) and it is recognized as the most important event for Object Technology in Europe. The combined exposition will consist of three dedicated technology areas: a COMDEX Internet Pavilion, an Object World Pavilion and an Open Systems Pavilion. The exposition has been designed to meet the visitors' expectations for Internet and Object Technology products on multi-vendors, and multi-platform systems as indicated by an independent study conducted by META Group on 139 of the 2,800 visitors of this year's Object World Frankfurt '96. The study indicated that: 72 % of attendees operate on Network Operating Systems 69% of attendees operate on UNIX platforms 64% of attendees operate on Windows Desktops 49% of attendees use object technology for Internet/Web application development. COMDEX Internet '97 and Object World Frankfurt '97 are sponsored and organized by Object World Corp. (a subsidiary of SOFTBANK COMDEX Inc.), Object Management Group and LogOn Technology Transfer GmbH. Information on Conferences and Exhibition: Christiane Sattler LogOn Technology Transfer GmbH Burgweg 14, D-61476 Kronberg/Ts., Germany phone: +49-6173-9558-53 fax: +49-6173-9404-20 e-mail: LogOn@omg.org Web: http://www.ltt.de Press Contact: Birgit Osterholt // Annegret Claushues LogOn Technology Transfer GmbH Burgweg 14, D-61476 Kronberg / Ts., Germany phone: +49-6173-9558-56//9558-55 fax: +49-6173-9404-20 e-mail: 101510.3135@compuserve.com (Osterholt) 101354.1424@compuserve.com (Claushues) Web: http://www.ltt.de Background Information: As of May 3, 1996, the Object World Series has been acquired by the producers of the most successful IT trade events worldwide, SOFTBANK COMDEX. This investment reflects a strategic initiative to join with Object Management Group in a move toward the expansion and commercialization of object technology around the world. Object World is the industry's most important event developed to focus on the commercial and practical aspects of applying object technology and provides an ideal forum for business and technical professionals to experience first hand the real-time practice of object technology standards. SOFTBANK COMDEX Inc. Since the introduction of the first COMDEX event in 1979, SOFTBANK COMDEX has continued to meet the growing needs of the global information technology marketplace. COMDEX/Fall, first held in Las Vegas in 1979, is now the largest trade show in North America. In 1996 and 1997 SOFTBANK COMDEX will produce over 40 information technology events in North America, South America, Europe and Asia, which are expected to include over 7,000 exhibiting companies and attract more than one million attendees from over 120 countries. Web: http://www.comdex.com LogOn Technology Transfer GmbH LogOn Technology Transfer GmbH, founded in 1991, is a privately owned company exclusively focused on the Internet and object technology markets. LogOn is organized into five operating divisions: Trade Shows, Marketing, PR, Training and Business. LogOn organizes Object World Frankfurt since 1993. LogOn is the official representative of the Object Management Group (OMG) for Austria, Benelux, France, Germany, Italy, Scandinavia and Switzerland. OMG is the largest software consortium worldwide with more than 700 company members dedicated to promoting the theory and practice of object technology (OT) for the development of distributed computing systems. Web: http://www.ltt.de From rem-conf-request@es.net Wed Nov 27 17:03:44 1996 Received: from mercury.lcs.mit.edu by osi-east.es.net with ESnet SMTP (PP); Wed, 27 Nov 1996 14:01:51 -0800 Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id RAA12173; Wed, 27 Nov 1996 17:01:48 -0500 X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Ian Wakeman cc: rem-conf@es.net Subject: Re: Summary of RTP scalability discussions In-reply-to: Your message of "Wed, 27 Nov 96 17:57:00 GMT." Date: Wed, 27 Nov 96 17:01:48 -0500 Message-ID: <5064.849132108@mercury.lcs.mit.edu> Sender: mjh@mercury.lcs.mit.edu X-Mts: smtp >With respect to the RTP report summaries, and scalable techniques for >getting hold of them - can I point people at the work I did on >scalable congestion control that was published with Thierry Turletti >and Jean Bolot in Sigcomm94? It had a scalable sender polling >technique that elicited random responses and gave reasonable estimates >of receiver groups within tens of rtts. I'd like to add that a scheme derived from Ian's work is what is used in the NTE Network Text Editor I wrote to perform NACK implosion avoidance in a scalable manner. Mark From rem-conf-request@es.net Wed Nov 27 17:49:35 1996 Received: from itd.nrl.navy.mil by osi-east.es.net with ESnet SMTP (PP); Wed, 27 Nov 1996 14:46:49 -0800 Received: from [132.250.92.68] (gumbo.itd.nrl.navy.mil) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA23886; Wed, 27 Nov 96 17:46:42 EST Message-Id: <9611272246.AA23886@itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Nov 1996 17:47:03 -0400 To: Ian Wakeman , rem-conf@es.net From: macker@itd.nrl.navy.mil (Joseph P. Macker) Subject: Re: Summary of RTP scalability discussions At 5:57 PM 11/27/96 +0000, Ian Wakeman wrote: >In addition, I have some unfinished work from about a year and a half >ago on automatic configuration of server hierarchies in multicast >networks, intended as a starting point for automatic key distribution >and for those using the logging approach out of Stanford for reliable >multicast. Essentially its an analysis of increasing scoped TTL >searches to graft on and create the appropriate number of levels in >the hierarchy. > >If anyone's interested, I'll dig it out and pass it over (since I >haven't found time in the last year and a bit to do anything with >it...). > >cheers >ian I'd be interested..sounds like good work....I was looking at something similar a year or so ago for a protocol idea based upon dynamic clustering hierarchy. At the time I was discouraged by what I thought was poor practice of using TTL threshold setting for multicast scoping. I envisioned this causing some undesirable, scalability behavior in TTL expanding ring search algorithms. Have I opened up a can of worms or is TTL threshold scoping standard practice diminishing? Or am I missing the boat here? -joe