From rem-conf-request@es.net Thu Aug 01 03:23:26 1996 Received: from necom830.hpcl.titech.ac.jp by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Aug 1996 00:22:37 -0700 From: Masataka Ohta Message-Id: <199608010722.QAA10061@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA10061; Thu, 1 Aug 1996 16:22:03 +0900 Subject: Re: Inconsistency in MPEG Payload format draft ? To: casner@precept.com (Stephen Casner) Date: Thu, 1 Aug 96 16:22:03 JST Cc: Philipp.Hoschka@sophia.inria.fr, rem-conf@es.net In-Reply-To: ; from "Stephen Casner" at Jul 31, 96 8:13 pm X-Mailer: ELM [version 2.3 PL11] Steve; > My recollection is that assigning 3 static payload types for MPEG > already seemed like a lot, and that MPEG1 System Streams and MPEG2 > Program streams were left for dynamic payload type assignment That's a self-contradiction. If dynamic payload type assignment were good enough, there is no reason to save numbering space of static payload types. So, the proper logic would be, because dynamic payload type assignment is not so good (at least in some situatin), we should assign static payload types conservatively > or > future static payload type definition if warranted. If MPEG1 System Streams and MPEG2 Program streams are important enough (which I don't think so), they should be assigned static payload numbers. Masataka Ohta From rem-conf-request@es.net Thu Aug 01 03:28:05 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Thu, 1 Aug 1996 00:27:23 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA19512; Thu, 1 Aug 1996 00:27:17 -0700 Date: Thu, 1 Aug 1996 00:27:16 -0700 (PDT) From: Stephen Casner To: Scott Petrack Cc: rem-conf@osi-east.es.net Subject: Re: Thou shalt be reasonable In-Reply-To: <9607282246.AA12687@precept.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Scott, > You gave a few examples where there were multiple "full streams" of > same-encoded media within a single session, multiplexed by > SSRC only. They might well have had distinct source UDP ports also if sent via separate sockets. Or, multiple SSRC's may have been sent on one socket. > If indeed one can say that there are only two kinds of acceptable > multiplexing - via different sessions or via SSRC within the same > session, then > I'd rather make rule 3. saying precisely this. But not multiplexing incompatible encodings/media. > Maybe now that there is a notion of "RTP context" (for compression) is > address+port+SSRC, then you want to say that you can multiplex/interleave > only via "RTP contexts." Within a context you can only switch encodings. One distinction you may be glossing over here is between source and destination address/port. The compression context needs to include source and destination address and port, plus SSRC which is associated with the source. The constraint of compatible encodings (e.g., all belonging to a single media type) would apply to multiplexing based on the source info (address/port/SSRC), while there are not constraints if the destination address/port is different. (Note that the source address and port are not really significant since they may be changed if packets flow through an RTP translator; the SSRC must be unique in the RTP session whether or not the source address/port is unique). -- Steve From rem-conf-request@es.net Thu Aug 01 04:59:58 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Aug 1996 01:59:25 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.7.5/8.7.3) with ESMTP id BAA03456; Thu, 1 Aug 1996 01:58:53 -0700 (PDT) Message-Id: <199608010858.BAA03456@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Masataka Ohta cc: casner@precept.com (Stephen Casner), Philipp.Hoschka@sophia.inria.fr, rem-conf@es.net Subject: Re: Inconsistency in MPEG Payload format draft ? In-reply-to: Your message of "Thu, 01 Aug 1996 16:22:03 +0200." <199608010722.QAA10061@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Aug 1996 01:58:52 -0700 From: Amancio Hasty >From The Desk Of Masataka Ohta : > If MPEG1 System Streams and MPEG2 Program streams are important > enough (which I don't think so), they should be assigned static > payload numbers. May I ask why do you think that mpeg1 system streams and mpeg2 program streams are not important? Tnks Amancio From rem-conf-request@es.net Thu Aug 01 05:04:45 1996 Received: from necom830.hpcl.titech.ac.jp by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Aug 1996 02:04:13 -0700 From: Masataka Ohta Message-Id: <199608010903.SAA10417@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA10417; Thu, 1 Aug 1996 18:03:34 +0900 Subject: Re: Inconsistency in MPEG Payload format draft ? To: hasty@rah.star-gate.com (Amancio Hasty) Date: Thu, 1 Aug 96 18:03:33 JST Cc: mohta@necom830.hpcl.titech.ac.jp, casner@precept.com, Philipp.Hoschka@sophia.inria.fr, rem-conf@es.net In-Reply-To: <199608010858.BAA03456@rah.star-gate.com>; from "Amancio Hasty" at Aug 1, 96 1:58 am X-Mailer: ELM [version 2.3 PL11] > >From The Desk Of Masataka Ohta : > > If MPEG1 System Streams and MPEG2 Program streams are important > > enough (which I don't think so), they should be assigned static > > payload numbers. > > May I ask why do you think that mpeg1 system streams and > mpeg2 program streams are not important? Because I don't think separated MPEG streams are important. Masataka Ohta From rem-conf-request@es.net Thu Aug 01 11:29:38 1996 Received: from gateway-gw.pictel.com by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Aug 1996 08:29:10 -0700 Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA09945; Thu, 1 Aug 96 11:29:09 EDT Received: from magicland.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1) id AA18425; Thu, 1 Aug 96 11:29:07 EDT Received: from moosejaw by magicland.pictel.com (SMI-8.6/SMI-SVR4) id LAA20656; Thu, 1 Aug 1996 11:27:09 -0400 Message-Id: <2.2.32.19960801152626.010d2590@magicland.pictel.com> X-Sender: webberr@magicland.pictel.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 01 Aug 1996 11:26:26 -0400 To: rem-conf@es.net From: Bob Webber Subject: Mirror of AVC ftp site in US Sorry for those of you who don't know who Mr Okubo is... The ftp site being mirrored as described below is the repository for draft versions and other files related to videoconferencing standards development in ITU-T Study Group 15. Files stored on this site include draft versions of documents for the H.323, H.310, and H.320 groups of videoconferencing standards. Some information about site organization is available from the file "This_ftp.txt". Bob >Return-Path: >X-Sender: webberr@magicland.pictel.com >Date: Wed, 31 Jul 1996 16:54:57 -0400 >To: rem-conf@es.net >From: Bob Webber >Subject: Mirror of AVC ftp site in US >content-length: 723 > >Hi, folks. PictureTel is pleased to announce that we are now providing a >mirror of the contents of Mr Okubo's ftp site on an accessible server in >Massachusetts. Use of the PictureTel mirror will make it easier to get >copies of documents posted by Mr Okubo and others for readers in the US and >Europe. > >The URL for the site is: >ftp://standard.pictel.com/avc-site/ >(or, ftp standard.pictel.com as user "anonymous" or "ftp" and give your >e-mail address for a password; cd avc-site) > >The mirror is updated from the original GCL site twice daily, at 5 AM and 8 >PM US Eastern time. > >If you experience any problems accessing the server, please contact Bob >Webber at e-mail webberr@pictel.com. > >Bob Webber >PictureTel Corporation > > > From rem-conf-request@es.net Thu Aug 01 15:46:58 1996 Received: from mercury.Sun.COM by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Aug 1996 12:46:28 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA18210; Thu, 1 Aug 1996 12:46:10 -0700 Received: from rebma. by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA03444; Thu, 1 Aug 1996 12:46:08 -0700 Received: by rebma. (5.x/SMI-SVR4) id AA21818; Thu, 1 Aug 1996 12:44:14 -0700 Date: Thu, 1 Aug 1996 12:44:14 -0700 From: hoffman@rebma.Eng.Sun.COM (Don Hoffman) Message-Id: <9608011944.AA21818@rebma.> To: Philipp.Hoschka@sophia.inria.fr, casner@precept.com Subject: Re: Inconsistency in MPEG Payload format draft ? Cc: rem-conf@es.net Reply-To: hoffman@Eng.Sun.COM X-Sun-Charset: US-ASCII >From: Stephen Casner > > >My recollection is that assigning 3 static payload types for MPEG >already seemed like a lot, and that MPEG1 System Streams and MPEG2 >Program streams were left for dynamic payload type assignment or >future static payload type definition if warranted. > >I hope to hear a comment from Don Hoffman and/or Michael Speer as >well. > -- Steve > Yes, that is my recollection also. But on reflection and more recent experience, I have formed the opinion that MPEG1 System Stream might merit a static assignment in a future payload type definitions. Don From rem-conf-request@es.net Thu Aug 01 16:40:38 1996 Received: from tis-mail.thepoint.net (actually tis-backup.thepoint.net) by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Aug 1996 13:39:38 -0700 Received: by tis-mail.thepoint.net with Microsoft Exchange (IMC 4.0.837.3) id <01BB7FBE.CA0E7700@tis-mail.thepoint.net>; Thu, 1 Aug 1996 15:33:29 -0400 Message-ID: From: Arlie Davis To: "'rem-conf@es.net'" , "'mbone@isi.edu'" Cc: Michael Jung Subject: Static versus dynamic payload types. Date: Thu, 1 Aug 1996 15:26:01 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The issue of static versus dynamic payload types has come up so frequently on this and other mailing lists, that it leads me to believe that the current system is inadequate. Developers of new applications who use static payload types fear the wrath of the gurus if they deploy their tools without the gurus' blessing. Developers who use dynamic payload types must either depend on the quality (and existence!) of the session tools, or must coordinate informing the receivers of the payload type through other means (email, sneaker-net, web page, whatever). This is frustrating, and hindering new application development. Here's my little mini-proposal. Why not throw out the existing system, and replace it with something much more flexible, extensible, and decentralized? Whenever a developer wants to create a new payload type, generate a new GUID (from DCE RPC / MS COM). (If you've never heard of GUIDs, they are unique, 128-bit numbers that can be generated on any machine that has an IEEE network card (Ethernet, Token Ring, etc.). GUIDs are generated using the MAC address of one of the machine's network cards and a few other things.) Most people would gripe about transmitting 16 bytes for just the payload type; I'm one of them. So, modify RTP to have two kinds of packets: stream data and stream description. Stream data is just what it sounds like; the SSRC (and network-layer address/port) would identify the stream. A stream description packet would be transmitted at the beginning of a transmission and then periodically during the transmission. The stream description would also have the SSRC and all the necessary information to uniquely identify the stream that is being described. The stream description would contain the (rather long) GUID that serves as the payload type, along with any other parameters that are deemed relevant. Even a relatively huge stream description packet (~256 bytes) could be transmitted once every few seconds. At worst, when a client joins an on-going transmission, it would have to wait a few seconds before being able to identify the contents of the packet. You could even do this within the context of the current RTP protocol. Define two static payload types: Stream data and stream description. The RTP header contains all the information needed to identify the stream; the payload type (from the current RTP header) would serve to distinguish stream data from stream descriptions. The two static payload types would allow people to assign their own new, dynamic payload types _without_ the need for externally coordinating the payload type. Please direct comments directly to me. I'll summarize to the list, if necessary. -- arlie From rem-conf-request@es.net Thu Aug 01 17:20:15 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Aug 1996 14:19:38 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.7.5/8.7.3) with ESMTP id OAA09260; Thu, 1 Aug 1996 14:17:41 -0700 (PDT) Message-Id: <199608012117.OAA09260@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: hoffman@Eng.Sun.COM cc: Philipp.Hoschka@sophia.inria.fr, casner@precept.com, rem-conf@es.net Subject: Re: Inconsistency in MPEG Payload format draft ? In-reply-to: Your message of "Thu, 01 Aug 1996 12:44:14 PDT." <9608011944.AA21818@rebma.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Aug 1996 14:17:40 -0700 From: Amancio Hasty >From The Desk Of Don Hoffman : > >From: Stephen Casner > > > > > >My recollection is that assigning 3 static payload types for MPEG > >already seemed like a lot, and that MPEG1 System Streams and MPEG2 > >Program streams were left for dynamic payload type assignment or > >future static payload type definition if warranted. > > > >I hope to hear a comment from Don Hoffman and/or Michael Speer as > >well. > > -- Steve > > > > Yes, that is my recollection also. But on reflection and more recent > experience, I have formed the opinion that MPEG1 System Stream might merit a > static assignment in a future payload type definitions. > > Don Please bear in mind that soon at least on the PC arena we are expecting hardware mpeg encoders to be widely available . Currently, there are plenty of hardware decoders available . For systems without hardware mpeg system stream support, it should not be difficult to break up an mpeg system stream. Amancio From rem-conf-request@es.net Thu Aug 01 20:26:14 1996 Received: from inet1.tek.com by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Aug 1996 17:25:29 -0700 Received: by inet1.tek.com id ; Thu, 1 Aug 1996 17:25:16 -0700 Received: from icebox.vndad.tek.com(128.181.120.101) by inet1 via smap (V1.3) id sma035638; Thu Aug 1 17:24:58 1996 Received: from icebox (localhost [127.0.0.1]) by icebox.vndad.tek.com (8.7.5/8.7.3) with ESMTP id RAA13283; Thu, 1 Aug 1996 17:30:01 -0700 (PDT) Message-Id: <199608020030.RAA13283@icebox.vndad.tek.com> To: hoffman@Eng.Sun.COM Cc: Philipp.Hoschka@sophia.inria.fr, casner@precept.com, rem-conf@es.net From: "Ted Brunner 503.627.1317" Subject: Re: Inconsistency in MPEG Payload format draft ? In-Reply-To: Your message of Thu, 01 Aug 1996 12:44:14 -0700. <9608011944.AA21818@rebma.> Date: Thu, 01 Aug 1996 17:30:00 -0700 Sender: tedb@vndad.tek.com > From: hoffman@rebma.Eng.Sun.COM (Don Hoffman) > > Yes, that is my recollection also. But on reflection and more recent > experience, I have formed the opinion that MPEG1 System Stream might merit a > static assignment in a future payload type definitions. Well, speaking as one who is working with MPEG1 System Stream encoders and decoders, I certainly support this notion. In addition to the simplification for me ;^) the other oft mentioned points are: MPEG1 gear is getting easier to come by, and a certain amount of material is already encoded. Ted Brunner Video and Networking Division Tektronix MS 50-490 ted.brunner@tek.com 14150 SW Karl Braun 503.627.1317 Beaverton OR 97005 From rem-conf-request@es.net Fri Aug 02 00:27:10 1996 Received: from dilbert.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Thu, 1 Aug 1996 21:26:30 -0700 Received: from dilbert.CS.Berkeley.EDU (localhost [127.0.0.1]) by dilbert.CS.Berkeley.EDU (8.7.4/8.6.9) with ESMTP id VAA08084 for ; Thu, 1 Aug 1996 21:25:43 -0700 Message-Id: <199608020425.VAA08084@dilbert.CS.Berkeley.EDU> X-Mailer: exmh version 1.6.4 10/10/95 To: rem-conf@es.net Subject: question re: multiple sources at one end system From: David Simpson X-url: http://www-plateau.cs.berkeley.edu/people/davesimp/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Aug 1996 21:25:42 -0700 Sender: davesimp@plateau.CS.Berkeley.EDU I have a question regarding how RTCP packets are handled when you have more than one source (ssrc) originating from a single application. (This can happen during a re-broadcast of a video conference or during a current conference in which a participant wants to transmit some stored video within the same session). Clearly each ssrc must send a sender report. However, since the multiple senders are all in the same app and presumably using the same socket to receive multicast packets, it would be redundant and a waste of bandwidth for each of the sources to send out receiver reports. Should only one source send the receiver reports? Also, even if some of the SDES information is different for each source, is there a problem with using the same cname for each of them (for synchronization purposes)? Thanks in advance for suggestions/clarifications. -Dave -- ---------------------------------------------------------------------------- David Simpson, davesimp@cs.berkeley.edu Graduate Student - Computer Science - UC Berkeley http://www-plateau.cs.berkeley.edu/~davesimp From rem-conf-request@es.net Fri Aug 02 17:54:16 1996 Received: from www45.inria.fr by osi-west.es.net with ESnet SMTP (PP); Fri, 2 Aug 1996 14:53:29 -0700 Received: by www45.inria.fr (8.7.5/8.6.12) id XAA18602; Fri, 2 Aug 1996 23:53:34 +0200 (MET DST) Message-Id: <199608022153.XAA18602@www45.inria.fr> To: rem-conf@es.net Subject: CfP: Real Time Multimedia and the Web Date: Fri, 02 Aug 1996 23:53:33 +0200 From: Philipp Hoschka To get full information, point your browser to: http://www.w3.org/pub/WWW/AudioVideo/RTMW96.html CALL FOR PARTICIPATION World Wide Web Consortium Workshop "Real Time Multimedia and the Web" (RTMW '96) October 24-25, 1996 INRIA-Sophia Antipolis - France SCOPE In the last year, there has been an increasing interest into the integration of audio and video into the Web. The Web offers the unique opportunity of fully integrating audio/video with many other media types (hypertext, images, ...), making Web technology a contender for the "television of the future". However, lacking both a forum for standardisation and a common reference implementation, current solutions for audio/video integration into the Web tend to be piecemeal and non-interoperable. The purpose of this workshop is to provide a forum for exploring future directions of standardisation process in this area within the W3C (WWW Consortium). Participants will be representatives of W3C member organisations and other qualified experts from research and industry. We solicit short position papers (one to maximally five pages) describing anything from a "wild idea" to a complete specification or implementations. The main areas of interest include (see also "W3C Activity: Audio and Video"): Building Web-based multimedia presentations Time representation and media synchronisation Defining audio/video presentation Audio/Video hyperlinks URL's for linking into audio and video files Addressing "streaming" audio/video resources via URL's Embedding URL's into audio and video streams Audio/Video media formats Describing the format of audio/video resources A common fall-back format for audio and video data Integration of RTP (Real Time Transport Protocol) Multicasting and the Web INFORMATION TO CONTRIBUTORS There will be a limit of 70 participants. There is no registration fee. Potential participants should submit to the workshop chair short position papers of one to five pages. Most importantly, the paper should state clearly your potential contribution to/idea on the integration of real-time multimedia into the Web. The papers can be submitted via e-mail (preferred) or in paper form. Allowed formats for e-mail submissions are, in order of preference: a URL to the paper, HTML, Postscript, PDF, RTF and ASCII. Papers will be reviewed by the program committee. Based on the reviews, we will ask a subset of participants to present talks. To maximize the time spent in interactive discussions, not all attendees will make presentations. However, all position papers will be included on the workshop website, and will appear in the printed participants' proceedings. W3C may also publish accepted papers. Note: The website will be available ot the general public, so position papers must be available for public dissemination. Workshop participants may also be interested visiting the "Protocol for High-Speed Networks" conference, which is scheduled at INRIA Sophia-Antipolis in the week after theW3C workshop. PUBLICATION Papers will be made available on the Web. Printed participants' proceedings will be distributed to workshop attendees. W3C may also publish accepted papers in other media. IMPORTANT DATES: Today: Send a message the workshop chair stating your intention to submit a paper, or your general interest in the workshop. Submission deadline: Friday, September 6, 1996 Notification of acceptance: Wednesday, September 18, 1996 Paper Website available: Wednesday, September 25, 1996 Workshop: Thursday, October 24 and Friday, October 25, 1996 ORGANIZATION COMMITTEE Workshop Chair: Philipp Hoschka, hoschka@w3.org fax: +33 93 65 77 65 INRIA Sophia Antipolis 2004 route des Lucioles, BP-93 06902 Sophia Antipolis, Cedex FRANCE Program Committee Members: Mostafa Ammar, Georgia Institute of Technology Ernst Biersack, Eurecom Jean Bolot, INRIA Stephen Casner, Precept (tentatively) Patrick Soquet, HAVAS Jim Gemmell, Microsoft Henry Holtzman, MIT Media Lab Christian Huitema, Bellcore (tentatively) Jeff Payne (tentatively), Progressive Networks Henning Schulzrinne, Columbia University VENUE The workshop will be held at INRIA Sophia Antipolis. Sophia Antipolis is a technology parc situated on the French Riviera, close to Cannes, Nice and the Italian border. It easily reachable from Nice International Airport (20 minutes by car). Direct flights from the US (New York) and most major airports in Europe are available. Hotel rooms at various price categories will be reserved and proposed to the participants. Last modified August 2, 1996. From rem-conf-request@es.net Sat Aug 03 03:46:58 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Sat, 3 Aug 1996 00:46:19 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA23636; Sat, 3 Aug 1996 00:45:40 -0700 Date: Sat, 3 Aug 1996 00:45:39 -0700 (PDT) From: Stephen Casner To: Arlie Davis Cc: rem-conf@es.net Subject: Re: Static versus dynamic payload types. In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Arlie, > The issue of static versus dynamic payload types has come up so > frequently on this and other mailing lists, that it leads me to believe > that the current system is inadequate. While I can understand this reaction, as you might guess I have a different view. I believe the dynamic payload type mechanism will work fine for most applications, but we just have to get over the hump in making the transition from an environment that only had static payload types to one that includes dynamic payload types as well. > Developers of new applications > who use static payload types fear the wrath of the gurus if they deploy > their tools without the gurus' blessing. Developers who use dynamic > payload types must either depend on the quality (and existence!) of the > session tools, or must coordinate informing the receivers of the payload > type through other means (email, sneaker-net, web page, whatever). It is a valid issue that sdr has not supported dynamic payload types up to now. However, Mark Handley is working on it. This is part of the hump. I believe it is reasonable to expect that applications can communicate dynamic payload type mappings out of band because they need to have some way to communicate at least the address and port information. Sure, if you communicate and enter the address/port by some manual means, then handling the payload type mappings the same way is impractical. However, I claim that any reasonable application design will not require communicating the address/port manually. > Why not throw out the existing system, and replace it with something > much more flexible, extensible, and decentralized? Whenever a developer > wants to create a new payload type, generate a new GUID (from DCE RPC / > MS COM). I believe there are some strong reasons to not throw out what we have developed and start over. One thing to consider in making your proposal is that what you describe is also harder to use than static payload types. I expect it would face a similar acceptance hump. > Most people would gripe about transmitting 16 bytes for just the payload > type; I'm one of them. So, modify RTP to have two kinds of packets: > stream data and stream description. Stream data is just what it sounds > like; the SSRC (and network-layer address/port) would identify the > stream. A stream description packet would be transmitted at the > beginning of a transmission and then periodically during the > transmission. The stream description would also have the SSRC and all > the necessary information to uniquely identify the stream that is being > described. The stream description would contain the (rather long) GUID > that serves as the payload type, along with any other parameters that > are deemed relevant. We've already been here. It's called the FMT (format) packet type for RTCP. Rather than modify RTP to have two types of packets, this idea used the existing separation of data and control functions in RTP/RTCP. The FMT packet carried a dynamic payload type number and the description of the payload format to which it was bound. However, the FMT scheme was removed from the proposal based on discussion at the March and July 1994 IETF meetings. The primary problem with this idea is the asynchrony between the data packets and the FMT packets. If you would like to review that discussion, please see ftp://ftp.isi.edu/mbone/avt/seattle-march94/minutes.94mar ftp://ftp.isi.edu/mbone/avt/seattle-march94/transcript.94mar ftp://ftp.isi.edu/mbone/avt/toronto-july94/minutes.94jul ftp://ftp.isi.edu/mbone/avt/toronto-july94/transcript.94jul The minutes are the summaries of the meetings for the IETF proceedings. The transcripts are rough transcripts taken from recordings of the meetings. The decision on FMT, from the July 94 minutes, was: It as agreed that FMT should not be defined in the main RTP spec, but that it could be defined in profiles as needed. For the initial Audio/Video profile, it was further agreed not to include FMT at this time. If a clear need is demonstrated later, we can define it then, as a profile extension. As stated, we could define FMT now. However, I believe that including these mappings in whatever session description the application will use is the better approach. -- Steve From rem-conf-request@es.net Sat Aug 03 03:55:02 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Sat, 3 Aug 1996 00:54:28 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA23639; Sat, 3 Aug 1996 00:54:20 -0700 Date: Sat, 3 Aug 1996 00:54:19 -0700 (PDT) From: Stephen Casner To: David Simpson Cc: rem-conf@es.net Subject: Re: question re: multiple sources at one end system In-Reply-To: <199608020425.VAA08084@dilbert.CS.Berkeley.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Clearly each ssrc must send a sender report. However, since the multiple > senders are all in the same app and presumably using the same socket > to receive multicast packets, it would be redundant and a waste of > bandwidth for each of the sources to send out receiver reports. Should > only one source send the receiver reports? I believe that is reasonable. You might also have a host which was a sender but chooses not to be a receiver. That host would send sender reports (RTCP SR packets), but would not include any reception report blocks. > Also, even if some of the SDES information is different for each source, is > there a problem with using the same cname for each of them (for > synchronization purposes)? Using the same CNAME is allowed. See section 6.2.2 in RFC 1889. -- Steve From rem-conf-request@es.net Sat Aug 03 10:30:20 1996 Received: from tis-mail.thepoint.net (actually tis-backup.thepoint.net) by osi-west.es.net with ESnet SMTP (PP); Sat, 3 Aug 1996 07:29:49 -0700 Received: by tis-mail.thepoint.net with Microsoft Exchange (IMC 4.0.837.3) id <01BB8126.B1D8DAE0@tis-mail.thepoint.net>; Sat, 3 Aug 1996 10:29:47 -0400 Message-ID: From: Arlie Davis To: 'Stephen Casner' Cc: "'rem-conf@es.net'" , Michael Jung Subject: RE: Static versus dynamic payload types. Date: Sat, 3 Aug 1996 09:26:53 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >---------- >From: Stephen Casner[SMTP:casner@precept.com] >Sent: Saturday, August 03, 1996 3:45 AM >To: Arlie Davis >Cc: rem-conf@es.net >Subject: Re: Static versus dynamic payload types. > >I believe there are some strong reasons to not throw out what we have >developed and start over. One thing to consider in making your >proposal is that what you describe is also harder to use than static >payload types. I expect it would face a similar acceptance hump. Er, I shouldn't have said "throw out the existing system", because what I propose would work within the current system, with no changes required of RTP at all, except the allocation of two static payload types. > >We've already been here. It's called the FMT (format) packet type for >RTCP. Rather than modify RTP to have two types of packets, this idea >used the existing separation of data and control functions in >RTP/RTCP. The FMT packet carried a dynamic payload type number and >the description of the payload format to which it was bound. > >However, the FMT scheme was removed from the proposal based on >discussion at the March and July 1994 IETF meetings. The primary >problem with this idea is the asynchrony between the data packets and >the FMT packets. If you would like to review that discussion, please >see Hmm. The FMT scheme seems similar, but more awkward. One problem with using RTCP (or SDR) is the issue of coordinating knowledge received in different streams. Combining the information in the same stream (in-band signalling) seems to address this. You gain nothing by transmitting the stream description in a different stream, because that stream must be received in order to process the data stream. I believe RTP, or any streaming media protocol, should be completely self-describing. No a priori knowledge should be necessary to know exactly what a stream contains. Thanks for the pointers, I'll check them out. And thanks for a well-reasoned reply. >-- arlie From rem-conf-request@es.net Sat Aug 03 15:11:00 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Sat, 3 Aug 1996 12:10:32 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 3 Aug 1996 20:10:18 +0100 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: Stephen Casner cc: Arlie Davis , rem-conf@es.net Subject: Re: Static versus dynamic payload types. In-reply-to: Your message of "Sat, 03 Aug 96 00:45:39 PDT." Date: Sat, 03 Aug 96 20:10:16 +0100 Message-ID: <23976.839099416@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >It is a valid issue that sdr has not supported dynamic payload types >up to now. However, Mark Handley is working on it. This is part of >the hump. sdr 2.2a17 and later (2.2a19 is now on ftp://cs.ucl.ac.uk/mice/sdr/ for SunOS,Solaris,Iris,HPUX,OSF1,Linux) does provide some support for dynamic payload types. It's a bit clunky right now, as I have no media tools properly supporting dynamic types to test with (rat 2.6 will do, but isn't finished yet...), but I expect I'll clean it up and make it more flexible as we gain more experience with the issues. Mark From rem-conf-request@es.net Sun Aug 04 01:29:28 1996 Received: from jupiter.cc.gettysburg.edu (actually gettysburg.edu) by osi-west.es.net with ESnet SMTP (PP); Sat, 3 Aug 1996 22:28:56 -0700 Received: from localhost ([0.0.0.0]) by jupiter.cc.gettysburg.edu with SMTP id AA10091 (5.67b/IDA-1.4.4 for ); Sun, 4 Aug 1996 01:32:56 -0400 Date: Sun, 4 Aug 1996 01:32:54 -0400 (EDT) From: "Charles A. Ross" Reply-To: "Charles A. Ross" To: rem-conf@es.net Subject: Rat, Vat, and Linux In-Reply-To: <23976.839099416@cs.ucl.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have noticed a problem with the vat for linux... and I am told that Rat dosent exist for linux yet... will it? The problem I noticed is that when I conference with a sun, and a linux machine (both running vat) the linux machine gets behind.. the linger the conferece is active the more it gets behind... I THINK this is because the /dev/audio on a sun is slightly faster than 8000... like 8012 or somthing and that a linux /dev/audio is exactly 8000... is there a fix for this? or has anyone else noticed this problem? Like I said... it exists with vat... havent tried rat.. cant find rat. I suppose I could hack my /dev/audio support to be the same as sun... ( what speed is a sun anyway? ) or somone could hack rat to use /dev/dsp for linux... i dunno just wondering -Chuck s253343@gettysburg.edu (717)-337-7105 From rem-conf-request@es.net Sun Aug 04 02:35:23 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Sat, 3 Aug 1996 23:34:56 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.7.5/8.7.3) with ESMTP id XAA09455; Sat, 3 Aug 1996 23:34:41 -0700 (PDT) Message-Id: <199608040634.XAA09455@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: "Charles A. Ross" cc: rem-conf@es.net Subject: Re: Rat, Vat, and Linux In-reply-to: Your message of "Sun, 04 Aug 1996 01:32:54 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 03 Aug 1996 23:34:40 -0700 From: Amancio Hasty >From The Desk Of "Charles A. Ross" : > /dev/audio on a sun is slightly faster than 8000... like 8012 or somthing > and that a linux /dev/audio is exactly 8000... is there a fix for this? or > has anyone else noticed this problem? Like I said... it exists with Curious how do you know that your soundcard is running at 8000hz on linux? BTW: which soundcard are you using? Tnks, Amancio From rem-conf-request@es.net Sun Aug 04 11:54:06 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Sun, 4 Aug 1996 08:53:32 -0700 Received: from rat.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 4 Aug 1996 16:53:16 +0100 To: "Charles A. Ross" cc: rem-conf@es.net, rat-trap@cs.ucl.ac.uk Subject: Re: Rat, Vat, and Linux In-reply-to: Your message of "Sun, 04 Aug 1996 01:32:54 EDT." Date: Sun, 04 Aug 1996 16:53:15 +0100 Message-ID: <1373.839173995@cs.ucl.ac.uk> From: Colin Perkins --> "Charles A. Ross" writes: >I have noticed a problem with the vat for linux... and I am told that Rat >dosent exist for linux yet... will it? We have a definite plan to port rat to linux, however there's no fixed timescale for this..... My guess is that it'll be done in a couple of months, but don't hold me to that! Colin From rem-conf-request@es.net Sun Aug 04 12:31:15 1996 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Sun, 4 Aug 1996 09:30:45 -0700 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14596(5)>; Sun, 4 Aug 1996 09:30:42 PDT Received: from localhost by ecco.parc.xerox.com with SMTP id <16136>; Sun, 4 Aug 1996 09:30:28 PDT To: "Charles A. Ross" cc: rem-conf@es.net Subject: Re: Rat, Vat, and Linux In-reply-to: Your message of "Sat, 03 Aug 96 22:32:54 PDT." Date: Sun, 4 Aug 1996 09:30:27 PDT Sender: Ron Frederick From: Ron Frederick Message-Id: <96Aug4.093028pdt."16136"@ecco.parc.xerox.com> In message you write: > The problem I noticed is that when I conference with a sun, and a linux > machine (both running vat) the linux machine gets behind.. the linger the > conferece is active the more it gets behind... I THINK this is because the > /dev/audio on a sun is slightly faster than 8000... like 8012 or somthing > and that a linux /dev/audio is exactly 8000... is there a fix for this? or > has anyone else noticed this problem? Like I said... it exists with > vat... havent tried rat.. cant find rat. > This isn't correct. The Sun audio device runs at 8000Hz, give or take a little bit of crystal error. The 8012 number you're thinking of came from the NeXT machine's audio input codec. Sun took the NeXT's audio file format, and so some of the Sun documentation and header files still mentioned the 8012 number, but it was never something they used. The only place where it comes up is that Suns will happily play NeXT (8012Hz) sound files without complaint at 8000 Hz, causing them to be slightly slower than they should be. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Sun Aug 04 13:12:11 1996 Received: from jupiter.cc.gettysburg.edu (actually gettysburg.edu) by osi-west.es.net with ESnet SMTP (PP); Sun, 4 Aug 1996 10:11:09 -0700 Received: from localhost ([0.0.0.0]) by jupiter.cc.gettysburg.edu with SMTP id AA04086 (5.67b/IDA-1.4.4 for ); Sun, 4 Aug 1996 13:14:34 -0400 Date: Sun, 4 Aug 1996 13:14:33 -0400 (EDT) From: "Charles A. Ross" To: Amancio Hasty Cc: "Charles A. Ross" , rem-conf@es.net Subject: Re: Rat, Vat, and Linux In-Reply-To: <199608040634.XAA09455@rah.star-gate.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > /dev/audio on a sun is slightly faster than 8000... like 8012 or somthing > > and that a linux /dev/audio is exactly 8000... is there a fix for this? or > > has anyone else noticed this problem? Like I said... it exists with > > Curious how do you know that your soundcard is running at 8000hz on linux? My sound card CAN run at 44100... but the /dev/audio support under linux is 8000... and I am not sure how fast the sun is sending.. it might be faster that 8000... which is what is seems like. I know linux /dev/audio is 8000 b/c i looked in the code ;) > > BTW: which soundcard are you using? SoundBlaster 16 -Chuck s253343@gettysburg.edu (717)-337-7105 From rem-conf-request@es.net Sun Aug 04 13:12:44 1996 Received: from jupiter.cc.gettysburg.edu (actually gettysburg.edu) by osi-west.es.net with ESnet SMTP (PP); Sun, 4 Aug 1996 10:12:00 -0700 Received: from localhost ([0.0.0.0]) by jupiter.cc.gettysburg.edu with SMTP id AA04212 (5.67b/IDA-1.4.4 for ); Sun, 4 Aug 1996 13:15:54 -0400 Date: Sun, 4 Aug 1996 13:15:53 -0400 (EDT) From: "Charles A. Ross" To: Colin Perkins Cc: "Charles A. Ross" , rem-conf@es.net, rat-trap@cs.ucl.ac.uk Subject: Re: Rat, Vat, and Linux In-Reply-To: <1373.839173995@cs.ucl.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 4 Aug 1996, Colin Perkins wrote: > We have a definite plan to port rat to linux, however there's no fixed > timescale for this..... My guess is that it'll be done in a couple of > months, but don't hold me to that! Do you know if it will take the "strange" /dev/audio into account? and if you would like a beta tester... i'm your man! -Chuck s253343@gettysburg.edu (717)-337-7105 From rem-conf-request@es.net Sun Aug 04 13:21:07 1996 Received: from jupiter.cc.gettysburg.edu (actually gettysburg.edu) by osi-west.es.net with ESnet SMTP (PP); Sun, 4 Aug 1996 10:19:38 -0700 Received: from localhost ([0.0.0.0]) by jupiter.cc.gettysburg.edu with SMTP id AA04468 (5.67b/IDA-1.4.4 for ); Sun, 4 Aug 1996 13:23:35 -0400 Date: Sun, 4 Aug 1996 13:23:35 -0400 (EDT) From: "Charles A. Ross" To: Ron Frederick Cc: rem-conf@es.net Subject: Re: Rat, Vat, and Linux In-Reply-To: <96Aug4.093028pdt."16136"@ecco.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 4 Aug 1996, Ron Frederick wrote: > In message > you write: > > The problem I noticed is that when I conference with a sun, and a linux > > machine (both running vat) the linux machine gets behind.. the linger the > > conferece is active the more it gets behind... I THINK this is because the > > /dev/audio on a sun is slightly faster than 8000... like 8012 or somthing > > and that a linux /dev/audio is exactly 8000... is there a fix for this? or > > has anyone else noticed this problem? Like I said... it exists with > > vat... havent tried rat.. cant find rat. > > > This isn't correct. The Sun audio device runs at 8000Hz, give or take a little > bit of crystal error. The 8012 number you're thinking of came from the NeXT > machine's audio input codec. Sun took the NeXT's audio file format, and so > some of the Sun documentation and header files still mentioned the 8012 number, > but it was never something they used. The only place where it comes up is that > Suns will happily play NeXT (8012Hz) sound files without complaint at 8000 Hz, > causing them to be slightly slower than they should be. Hmm.... now that you mention it that sounds right... I do remember that it was NeXT that changed the number... is there any way in linux or sunos to actually test the sampling and playback rate of the /dev/audio? Like I said... somthing is screwey... when I converence for a long time... i get WAY behind... the wort it got for me was about 10-15 seconds of lagtime and that was aftetr about 2 hours of conference time... I did a little bit of math... and if those 12 bytes per second were backing up... then after 2 hours it would be the equiv of about 10 seconds... So i just assumed that this was the problem... any other suggestions? -Chuck s253343@gettysburg.edu (717)-337-7105 From rem-conf-request@es.net Sun Aug 04 14:26:58 1996 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Sun, 4 Aug 1996 11:25:26 -0700 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <15095(1)>; Sun, 4 Aug 1996 11:25:20 PDT Received: from localhost by ecco.parc.xerox.com with SMTP id <16136>; Sun, 4 Aug 1996 11:25:16 PDT To: "Charles A. Ross" cc: rem-conf@es.net Subject: Re: Rat, Vat, and Linux In-reply-to: Your message of "Sun, 04 Aug 96 10:23:35 PDT." Date: Sun, 4 Aug 1996 11:25:15 PDT Sender: Ron Frederick From: Ron Frederick Message-Id: <96Aug4.112516pdt."16136"@ecco.parc.xerox.com> In message you write: > Hmm.... now that you mention it that sounds right... I do remember that it > was NeXT that changed the number... is there any way in linux or sunos to > actually test the sampling and playback rate of the /dev/audio? > Like I said... somthing is screwey... when I converence for a long time... > i get WAY behind... the wort it got for me was about 10-15 seconds of > lagtime and that was aftetr about 2 hours of conference time... I did a > little bit of math... and if those 12 bytes per second were backing up... > then after 2 hours it would be the equiv of about 10 seconds... > So i just assumed that this was the problem... any other suggestions? > The only time you should see an ever-increasing lag like that with vat is if you are running both ends with silence suppression turned off and you are transmitting continuously for the entire two hours. Otherwise, at the end of each talk spurt, vat will let the audio device drain, and any relative error between the two sample rates won't be a factor. If you're seeing lag like that and you aren't transmitting continuously, I would suspect that vat's playback point setting algorithm is getting in your way, perhaps because your _system_ clock is running fast or slow compared to the other machine. You might try running something like NTP on your machine if you can find a nearby time server. If you are transmitting continuously, it's not hard to measure the rate, but it'll only be as good as your system clock is. Here's a sample program. On my SunOS machine, it returns 8000 +/- about 0.25. That error is mostly system scheduling issues, and not real sample clock error. The program below should take about 2 minutes to run. #include #include #include main() { int audiofd; struct timeval t0, t1; char buf[1000000]; gettimeofday(&t0, NULL); audiofd = open("/dev/audio", O_RDONLY); read(audiofd, buf, sizeof(buf)); gettimeofday(&t1, NULL); printf("Rate = %.2f Hz\n", sizeof(buf)/((t1.tv_sec-t0.tv_sec)+ (t1.tv_usec-t0.tv_usec)/1000000.)); } When I did detailed measurements on a Sun, I actually found that the audio clock was a lot more stable that the system clock. Things like the Sun synctodr or an NTP client would keep the long term average of the system clock basically right, but only by alternately drifting it up and down. When I plotted the system clock vs. the audio clock, I ended up getting a triangle wave! -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Sun Aug 04 16:14:15 1996 Received: from ell.ee.lbl.gov by osi-west.es.net with ESnet SMTP (PP); Sun, 4 Aug 1996 13:13:01 -0700 Received: by ell.ee.lbl.gov (8.7.5/1.43r) id NAA05236; Sun, 4 Aug 1996 13:12:56 -0700 (PDT) From: mccanne@ee.lbl.gov (Steven McCanne) Message-Id: <199608042012.NAA05236@ell.ee.lbl.gov> To: "Charles A. Ross" cc: Amancio Hasty , rem-conf@es.net Subject: Re: Rat, Vat, and Linux In-reply-to: Your message of Sun, 04 Aug 96 13:14:33 -0400. Date: Sun, 04 Aug 96 13:12:56 PDT > I know linux /dev/audio is 8000 b/c i looked in the code ;) > >> BTW: which soundcard are you using? > > SoundBlaster 16 Actually, the soundblaster crystal frequency and divide-down counter don't allow you to get exactly 8KHz (even if you request 8KHz from the linux audio API). So I think it's your linux host that is off while your sun is on. Steve From rem-conf-request@es.net Sun Aug 04 17:52:55 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Sun, 4 Aug 1996 14:52:14 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.7.5/8.7.3) with ESMTP id OAA05365; Sun, 4 Aug 1996 14:51:56 -0700 (PDT) Message-Id: <199608042151.OAA05365@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: "Charles A. Ross" cc: rem-conf@es.net Subject: Re: Rat, Vat, and Linux In-reply-to: Your message of "Sun, 04 Aug 1996 13:14:33 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 Aug 1996 14:51:55 -0700 From: Amancio Hasty >From The Desk Of "Charles A. Ross" : > > I know linux /dev/audio is 8000 b/c i looked in the code ;) > Sorry I don't buy this sort of argument . Can you write a little program to actually test your assumptions. Amancio From rem-conf-request@es.net Sun Aug 04 20:36:01 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Sun, 4 Aug 1996 17:35:31 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.7.5/8.7.3) with ESMTP id RAA06299; Sun, 4 Aug 1996 17:35:12 -0700 (PDT) Message-Id: <199608050035.RAA06299@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Ron Frederick cc: "Charles A. Ross" , rem-conf@es.net Subject: Re: Rat, Vat, and Linux In-reply-to: Your message of "Sun, 04 Aug 1996 11:25:15 PDT." <96Aug4.112516pdt."16136"@ecco.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 Aug 1996 17:35:10 -0700 From: Amancio Hasty >From The Desk Of Ron Frederick : > you are running both ends with silence suppression turned off and you are > transmitting continuously for the entire two hours. Otherwise, at the end of > each talk spurt, vat will let the audio device drain, and any relative error > between the two sample rates won't be a factor. For interactive sessions, is it possible to modify vat to mark end of talk spurt every few packets? Tnks, Amancio From rem-conf-request@es.net Mon Aug 05 00:58:20 1996 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Sun, 4 Aug 1996 21:57:52 -0700 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <16066(4)>; Sun, 4 Aug 1996 21:57:45 PDT Received: from localhost by ecco.parc.xerox.com with SMTP id <16136>; Sun, 4 Aug 1996 21:57:38 PDT To: Amancio Hasty cc: "Charles A. Ross" , rem-conf@es.net Subject: Re: Rat, Vat, and Linux In-reply-to: Your message of "Sun, 04 Aug 96 17:35:10 PDT." <199608050035.RAA06299@rah.star-gate.com> Date: Sun, 4 Aug 1996 21:57:37 PDT Sender: Ron Frederick From: Ron Frederick Message-Id: <96Aug4.215738pdt."16136"@ecco.parc.xerox.com> In message <199608050035.RAA06299@rah.star-gate.com> you write: > For interactive sessions, is it possible to modify vat to mark end of talk > spurt every few packets? > Sorry, no. Doing that wouldn't really work anyway... It would cause the audio to break up as it tried to reposition the playout point at each false end marker. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Mon Aug 05 03:06:18 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Aug 1996 00:05:16 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.7.5/8.7.3) with ESMTP id AAA07511; Mon, 5 Aug 1996 00:04:58 -0700 (PDT) Message-Id: <199608050704.AAA07511@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Ron Frederick cc: "Charles A. Ross" , rem-conf@es.net Subject: Re: Rat, Vat, and Linux In-reply-to: Your message of "Sun, 04 Aug 1996 21:57:37 PDT." <96Aug4.215738pdt."16136"@ecco.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Aug 1996 00:04:57 -0700 From: Amancio Hasty >From The Desk Of Ron Frederick : > In message <199608050035.RAA06299@rah.star-gate.com> you write: > > For interactive sessions, is it possible to modify vat to mark end of talk > > spurt every few packets? > > > Sorry, no. Doing that wouldn't really work anyway... It would cause the audi o > to break up as it tried to reposition the playout point at each false end > marker. So you are trying to say that if I modify vat to send an end of talk spur lets say every 4 audio packets that this wouldn't work?? Thats interesting... if thats the case then it sounds to me that vat needs more work 8) Regards, Amancio From rem-conf-request@es.net Mon Aug 05 03:44:10 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Aug 1996 00:43:24 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.7.5/8.7.3) with ESMTP id AAA07740; Mon, 5 Aug 1996 00:43:08 -0700 (PDT) Message-Id: <199608050743.AAA07740@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: "Charles A. Ross" cc: rem-conf@es.net Subject: Re: Rat, Vat, and Linux In-reply-to: Your message of "Sun, 04 Aug 1996 22:34:31 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Aug 1996 00:43:07 -0700 From: Amancio Hasty >From The Desk Of "Charles A. Ross" : > > On Sun, 4 Aug 1996, Amancio Hasty wrote: > > >From The Desk Of "Charles A. Ross" : > > > > > > I know linux /dev/audio is 8000 b/c i looked in the code ;) > > > > > > > Sorry I don't buy this sort of argument . Can you write a little > > program to actually test your assumptions. > > Ok.. I did... according to a variation on the program that Ron Frederick > wrote... for linux: 7999.24 Hz > for sun: 7996.48 Hz (it only works on some suns apparently... > for one I got 248299150.82 Hz.. i dont beleive that ;) Well, okay... On my FreeBSD box I use this to check out my soundcards. Currently, I am hacking on and off on my GUS PnP. {hasty} ./test . . . 5816000 727.066 7999.28 5824000 728.066 7999.28 5832000 729.066 7999.28 5840000 730.066 7999.28 5848000 731.066 7999.28 5856000 732.066 7999.28 5864000 733.066 7999.28 5872000 734.066 7999.29 5880000 735.066 7999.29 5888000 736.066 7999.29 5896000 737.066 7999.29 5904000 738.066 7999.29 5912000 739.066 7999.29 5920000 740.066 7999.29 5928000 741.066 7999.29 5936000 742.066 7999.29 5944000 743.066 7999.29 5952000 744.066 7999.3 5960000 745.066 7999.29 5968000 746.066 7999.3 5976000 747.066 7999.3 5984000 748.066 7999.3 My GUS PnP oscillates between 7999 and 7999.99 . The card is a bit more accurate is just I have been hacking on the sound driver. If the audio tool being use is vat, on FreeBSD and Linux systems using full duplex audio it is important to set the buffer size . The test program sets the buffer size to 160 bytes. The GUS PnP is interesting because it supports 8 or 16 bit full duplex dma unlike the SB16 which supports 8 bit dma one way and 16bit dma the other way. The following code is test program written by Jim Lowe #include #include #include #include #include #include #include char *dev="/dev/dsp"; int blocksize = 160; main(int ac, char **av) { struct timeval tv, start; int fd; fd_set rfd; int cc; int i; double u; int foo[9000]; if(ac>1) dev = av[1]; if((fd=open(dev, O_RDWR)) < 0) { perror("open failed\n"); exit(-1); } if(ioctl(fd, SNDCTL_DSP_SETBLKSIZE, &blocksize) < 0) { printf("Setting blocksize failed: %s\n", strerror(errno)); } read(fd, dev, 1); gettimeofday(&start, 0); cc = 0; i = 0; FD_ZERO(&rfd); while (1) { int n; char buf[blocksize]; FD_SET(fd, &rfd); select(fd+1, &rfd, 0, 0, 0); n = read(fd, buf, blocksize); usleep(4); if (n < 0) { perror("read"); exit(1); } if(n!=blocksize) printf("read %d, wanted blocksize\n", n); cc += n; if (++i >= 50) { i = 0; gettimeofday(&tv, 0); u = tv.tv_sec - start.tv_sec; u += 1e-6 * (tv.tv_usec - start.tv_usec); printf("%d %lg %lg\n", cc, u, (double)cc / u); fflush(stdout); } } } From rem-conf-request@es.net Mon Aug 05 09:07:08 1996 Received: from rzdspc1.informatik.uni-hamburg.de by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Aug 1996 06:06:29 -0700 Received: from ro2.informatik.uni-hamburg.de (ro2.informatik.uni-hamburg.de [134.100.15.162]) by rzdspc1.informatik.uni-hamburg.de (8.7.5/8.7.3) with SMTP id PAA18850 for ; Mon, 5 Aug 1996 15:06:25 +0200 (MET DST) Received: from ro4.informatik.uni-hamburg.de by ro2.informatik.uni-hamburg.de (4.1/SMI-4.1/RZ-1.04/s) with SMTP id ; Mon, 5 Aug 96 15:04:32 +0200 From: richter@ro2.informatik.uni-hamburg.de (Jan-Peter Richter) Message-Id: <9608051304.AA02920@ro2.informatik.uni-hamburg.de> Subject: CFP 3rd Int' Conf' on Analytical and Numerical Modelling Techniques with the application to Quality of Service Modelling To: rem-conf@es.net Date: Mon, 5 Aug 1996 15:06:23 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Call for Papers 3rd International Conference on Analytical and Numerical Modelling Techniques with the application to QUALITY OF SERVICE (QoS) MODELLING Singapore, September 1-4, 1997 The submission of papers is solicited for the "3. Analytical and Numerical Modelling Techniques Conference" on QUALITY OF SERVICE (QoS) MODELLING which is organized by SCS as part of the 1st World Congress on Systems Simulation. Technical Background: -------------------- Recently, the concept of Quality of Service (QoS) has attracted a lot of attention in research and development of high speed computer and communication networks with multimedia applications. Real-time and other qualities such as guaranteed performance and dependability are vital properties of offered services to be provided by future communication networks. Contractual relationships between service user and service provider regarding prospective services and their required qualities have to be realized. Guarantees should be given even in the presence of stochastic uncertainties. Network components may fail, transmission errors cannot be totally avoided, or temporary overload conditions are likely to occur due to incorporated multiplexing techniques in the usage of system resources. Quantitative modeling represents a promising approach to appropriately support system design and dynamic management. Accurate projections of computer and communication systems' behavior are needed. The first challenge for QoS modeling comes from the fact that timeliness, performance, and dependability properties are equally vital issues for the applications. The second challenge is due to the peculiar novelty that application and customer specific metrics rather than system related ones are of major interest. As a third challenge it becomes increasingly important that QoS support is provided in heterogeneous environments. Original papers which have not been published and which deal with QoS related quantitative modeling topics are solicited for submission. The conference focus is on modeling techniques and tools as well as on evaluation studies relevant to the theme. QoS modeling combined with practical implementation experience is of predominant interest. The following is an incomplete list of topics relevant to the conference: - QoS modeling techniques and tools for evaluation of multimedia services in high speed networks - QoS management - QoS specification - QoS mapping - QoS negotiation and admission control - QoS modeling and evaluation case studies - QoS modeling and practical implementation experience - QoS support in heterogeneous environments - User oriented QoS modeling - Neurocomputing and cognitive modeling for QoS support - Real-time services - Adaptive and reconfigurable systems - Responsive systems modeling - Dependability evaluation - Performability modeling - Stochastic Petri net models - Queueing systems - Markov models - Simulation studies - Measurement techniques and studies ------------------------------------------------------------------------ ------------------------------------------------------------------------ Conference Chair: ---------------- Gunter Bolch Department of Computer Science - OS, University Erlangen-Nuremberg Martensstrasse 1, D-91058 Erlangen, Germany bolch@informatik.uni-erlangen.de Tel.: +49 9131 85-7903, Fax: +49 9131 39388 Program Chair: -------------- Hermann de Meer Department of Computer Science - TKRN, University of Hamburg Vogt-Koelln-Strasse 30, D-22527, Hamburg, Germany demeer@informatik.uni-hamburg.de Tel: +49 40 5494-2347, Fax: +49 40 5494-2328 Program Committee: ----------------- Andres Albanese, Univ. of California at Berkeley, USA Gordon Blair, Lancaster Univ., UK Andrew Campbell, Columbia Univ., USA Mario Dal Cin, Erlangen Univ., Germany Petre Dini, Univ. of Montreal, Canada Winfried Dulz, Erlangen Univ., Germany Pankaj Garg, Hewlett Packard Lab. at Palo Alto, USA Stefan Greiner, Erlangen Univ., Germany Roch Guerin, IBM T.J. Watson Research Center, USA Guenter Haring, Univ. of Vienna, Austria Boudewijn Haverkort, Aachen Univ., Germany Ulrich Herzog, Erlangen Univ., Germany Gardeep Hura, Nanyang Technological University, Singapore Klaus Irmscher, Bergakademie Freiberg, Germany Werner Jarschel, Siemens AG Erlangen, Germany Yoshiaki Kakuda, Osaka Univ., Japan David Kirsh, Univ. of California at San Diego, USA Edward Knightly, Rice Univ., USA Udo Krieger, Deutsche Telekom AG Darmstadt, Germany Jorg Liebeherr, University of Virginia, USA Dimitris Logothetis, Lucent Technologies, USA Miroslaw Malek, Humboldt Univ. Berlin, Germany Jan de Meer, GMD-Fokus Berlin, Germany Bruno Mueller-Clostermann, Essen Univ., Germany Jogesh Muppala, Hong Kong University of Science and Technology, Hong Kong Victor Nicola, Univ. of Twente, The Netherlands Giovanni Pacifici, IBM T.J. Watson Research Center, USA Antonio Puliafito, Universita di Catania, Italy Jan-Peter Richter, Univ. of Hamburg, Germany Miklos Telek, Budapest Univ., Hungary Satish Tripathi, Univ. of Maryland, USA Kishor Trivedi, Duke University, USA Andreas Vogel, Univ. of Queensland, Australia Sandy Wang, Stratacom at Palo Alto, USA Bernd Wolfinger, Univ. of Hamburg, Germany Martina Zitterbart, Braunschweig Univ., Germany Deadlines: --------- Paper Submission: Jan. 10, 1997 Notification of Acceptance: April 1, 1997 Camera Ready Copy: May 15, 1997 Submission Policy: ----------------- The submission of FIVE COPIES of double-spaced full manuscripts is solicited. The length of double-spaced papers should not exceed 15 PAGES, including figures and references. The camera ready copy will be required to be in double column format, not exceeding five pages of length. The papers should be sent to: Secretariat of the 1st WORLD CONGRESS ON SYSTEMS SIMULATION ANMT: QoS Modeling Attention: Mr. Jonnovan Hong c/o IEEE Singapore Section 59D Science Park Drive, The Fleming Singapore 118243 Republic of Singapore Tel: +65 773 1141 Fax: +65 773 1142 ieeesgp@pacific.net.sg ATTENTION! Please help to speed up the reviewing process and submit also a POSTSCRIPT version of your paper by EMAIL to the program chair: demeer@informatik.uni-hamburg.de Publication Policy: ------------------ All submitted papers will be reviewed by at least four members of the international program committee. Accepted papers will be published in the IEEE Computer Society and SCS-Europe Publishing House proceedings. Exhibitions and Tutorials: ------------------------- Exhibitions, tutorials, and vendor sessions are also solicited for presentation. If interested, please contact the appropriate conference or program chair person. Organization: ------------ Organized and sponsored by: SCS The Society for Computer Simulation International National University of Singapore Nanyang Technical University, Singapore University Erlangen-Nuremberg, Germany University of Ottawa, Canada Participating Societies: ASIM, CASS, CSSS, FRANKOSIM, HSS, IEEE Singapore, ISCS, JSST, KSS, SCS Europe, SCS International, SiE, SIMS, UKSS, NUS, NTU From rem-conf-request@es.net Mon Aug 05 11:07:41 1996 Received: from FNAL.FNAL.Gov by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Aug 1996 08:07:07 -0700 Received: from munin.fnal.gov ("port 4405"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I7WVK1GDEG001MCB@FNAL.FNAL.GOV>; Mon, 05 Aug 1996 10:07:02 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id KAA20399; Mon, 05 Aug 1996 10:05:25 -0500 (CDT) Date: Mon, 05 Aug 1996 10:05:25 -0500 From: Matt Crawford Subject: Re: Rat, Vat, and Linux In-reply-to: "05 Aug 1996 00:04:57 PDT." <"199608050704.AAA07511"@rah.star-gate.com> Sender: crawdad@munin.fnal.gov To: Amancio Hasty Cc: rem-conf@es.net Message-id: <199608051505.KAA20399@munin.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{ So you are trying to say that if I modify vat to send an end of talk spur > lets say every 4 audio packets that this wouldn't work?? > Thats interesting... if thats the case then it sounds to me that vat > needs more work I believe you haven't given this enough thought. The end-of-spurt marker indicates that the sound following the mark need not be carefully synchronized with the sound before the mark. You're proposing to send this marker many times per syllable. I don't think it's vat that needs more work. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A From rem-conf-request@es.net Mon Aug 05 12:41:32 1996 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Aug 1996 09:40:46 -0700 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <15456(5)>; Mon, 5 Aug 1996 09:40:04 PDT Received: from localhost by ecco.parc.xerox.com with SMTP id <16136>; Mon, 5 Aug 1996 09:39:52 PDT To: Amancio Hasty cc: "Charles A. Ross" , rem-conf@es.net Subject: Re: Rat, Vat, and Linux In-reply-to: Your message of "Mon, 05 Aug 96 00:04:57 PDT." <199608050704.AAA07511@rah.star-gate.com> Date: Mon, 5 Aug 1996 09:39:51 PDT Sender: Ron Frederick From: Ron Frederick Message-Id: <96Aug5.093952pdt."16136"@ecco.parc.xerox.com> In message <199608050704.AAA07511@rah.star-gate.com> you write: > So you are trying to say that if I modify vat to send an end of talk spur > lets say every 4 audio packets that this wouldn't work?? > > Thats interesting... if thats the case then it sounds to me that vat > needs more work 8) > I don't think you understand what "ending a talk spurt" means. The whole point of marking talk spurts is to identify which set of audio packets should all be played with the same playout delay. If you take a single talk spurt that was recorded continuously at the sender and you arbitrarily break it into small pieces, marking each as a new talk spurt to the receiver, then the receiver is free to insert extra silence gaps between these smaller pieces. That wouldn't sound very good, would it? -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Mon Aug 05 17:57:51 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Aug 1996 14:56:41 -0700 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.5/8.7.3) with ESMTP id OAA03547; Mon, 5 Aug 1996 14:56:29 -0700 (PDT) Message-Id: <199608052156.OAA03547@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Matt Crawford cc: rem-conf@es.net Subject: Re: Rat, Vat, and Linux In-reply-to: Your message of "Mon, 05 Aug 1996 10:05:25 CDT." <199608051505.KAA20399@munin.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Aug 1996 14:56:28 -0700 From: Amancio Hasty >From The Desk Of Matt Crawford : > I believe you haven't given this enough thought. The end-of-spurt > marker indicates that the sound following the mark need not be Those darn semantics... Okay, the problem to solve is how to keep two vat clients in sync when we know that the clocks are not accurate. Additionally, for interactive sessions if silence suppression is not used to keep the duration of the playback buffer relatively small. vat still needs work, A.H. From rem-conf-request@es.net Mon Aug 05 18:02:28 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Aug 1996 15:00:07 -0700 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.5/8.7.3) with ESMTP id OAA03561; Mon, 5 Aug 1996 14:59:22 -0700 (PDT) Message-Id: <199608052159.OAA03561@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Ron Frederick cc: "Charles A. Ross" , rem-conf@es.net Subject: Re: Rat, Vat, and Linux In-reply-to: Your message of "Mon, 05 Aug 1996 09:39:51 PDT." <96Aug5.093952pdt."16136"@ecco.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Aug 1996 14:59:22 -0700 From: Amancio Hasty >From The Desk Of Ron Frederick : > In message <199608050704.AAA07511@rah.star-gate.com> you write: > is free to insert extra silence gaps between these smaller pieces. That > wouldn't sound very good, would it? You are right however, I will never insert silence gaps between talk spurs. Regards, Amancio From rem-conf-request@es.net Mon Aug 05 18:50:59 1996 Received: from aland.bbn.com by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Aug 1996 15:49:23 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id PAA01370; Mon, 5 Aug 1996 15:48:31 -0700 (PDT) Message-Id: <199608052248.PAA01370@aland.bbn.com> To: rem-conf@es.net cc: karp@eecs.harvard.edu Subject: ACM SIGCOMM '96 and the MBONE Reply-To: Craig Partridge From: Craig Partridge Date: Mon, 05 Aug 96 15:48:31 -0700 Sender: craig@aland.bbn.com Hi folks: More detailed information will follow later, but so that you are aware this is coming. ACM SIGCOMM '96 will be doing two MBONE broadcasts: * On August 27th, there will be an MBONE workshop at SIGCOMM which will be broadcast from approximately 9 AM to 5 PM Pacific Time. * On August 28th, we will MBONE the first two sessions of the the conference: Vint Cerf's SIGCOMM Award address and the first three paper presentations (this broadcast will be from 9 AM to 12:30 PM Pacific Time). These two broadcasts are a modest test of SIGCOMM's plan to make larger use of the MBONE at future conferences. Thanks! Craig E-mail: craig@aland.bbn.com or craig@bbn.com From rem-conf-request@es.net Mon Aug 05 21:24:59 1996 Received: from sgi.sgi.com (actually SGI.COM) by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Aug 1996 18:24:04 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA06290 for <@sgi.engr.sgi.com:rem-conf@es.net>; Mon, 5 Aug 1996 18:23:59 -0700 Received: from pimtest.engr.sgi.com (pimtest.engr.sgi.com [150.166.75.13]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id SAA25004 for <@cthulhu.engr.sgi.com:rem-conf@es.net>; Mon, 5 Aug 1996 18:23:59 -0700 Received: (from ahelmy@localhost) by pimtest.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA20540; Mon, 5 Aug 1996 18:23:58 -0700 From: Ahmed Helmy Message-Id: <9608051823.ZM20538@pimtest.engr.sgi.com> Date: Mon, 5 Aug 1996 18:23:57 -0700 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: rem-conf@es.net Subject: vat/vic update period Cc: nowicki@pimtest.engr.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Greetings, What is the current group participants information update period for vat and vic ? and is this period scaled up when the number of group participants grows.. ??! thanks, -A From rem-conf-request@es.net Mon Aug 05 22:51:45 1996 Received: from rx7.ee.lbl.gov by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Aug 1996 19:51:05 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id TAA12739; Mon, 5 Aug 1996 19:48:22 -0700 Message-Id: <199608060248.TAA12739@rx7.ee.lbl.gov> To: Ahmed Helmy cc: rem-conf@es.net, nowicki@pimtest.engr.sgi.com Subject: Re: vat/vic update period In-reply-to: Your message of Mon, 05 Aug 96 18:23:57 PDT. Date: Mon, 05 Aug 96 19:48:22 PDT From: Van Jacobson > What is the current group participants information update period > for vat and vic ? and is this period scaled up when the number > of group participants grows.. ??! The answer to the second question is yes. For the other part of the question, read section 6.2 of RFC1889 (RTP). Vic follows it exactly (in fact, vic was used to develop & prototype the algorithm in sec 6.2). A typical session is 128kb/s and the rtcp bw is 5% of that or about 800 bytes/sec. Average report size is around 100 bytes or about 8 reports/sec. aggregate. The minimum per-member report interval is 5 sec so that tends to be the interval for 'small' sessions (<40 members). Above this session size, the per-member interval stretches out linearly proportional to the number of members. - Van From rem-conf-request@es.net Mon Aug 05 23:59:21 1996 Received: from broon.off.connect.com.au by osi-west.es.net with ESnet SMTP (PP); Mon, 5 Aug 1996 20:58:48 -0700 Received: from connect.com.au (ggm@localhost) by broon.off.connect.com.au with ESMTP id NAA29357 (8.7.4/IDA-1.6 for ); Tue, 6 Aug 1996 13:58:40 +1000 (EST) X-Authentication-Warning: broon.off.connect.com.au: ggm owned process doing -bs X-Mailer: exmh version 1.6.6 3/24/96 To: rem-conf@es.net Subject: sdr announcement cycle time. In-reply-to: Your message of "Mon, 05 Aug 1996 19:48:22 PDT." <199608060248.TAA12739@rx7.ee.lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Aug 1996 13:58:09 +1000 Message-ID: <29356.839303889@connect.com.au> From: George Michaelson We find locally that the sdr session reporting is inadequate even for very small groups of people. the period over which individuals come online and expect to find a fresh sdr primed with details is very large, and close to the begin time of a booked slot, the frequency of announcements should rise to at least 1 every 10-15 seconds. The behaviour of the entire system (sdr/vat/wb etc) when details of sessions change and users are bound inside the tools is also a problem. Bugs in sdr cause important details of announced sessions to change (like addresses and ttls) and rendesvous across multiple ttl multiple address sessions is almost impossible. If the sdr back-end protocol included some kind of "re-bind now" message this would definately help. I also think a re-advertize button and function would make sense, instead of requiring session managers to make spurious edits to existing sessions to force re-propagation of information. This stuff crosses the boundary of GUI specifics into protocol issues. Thats why I'm posting here. Maybe mmmusic would have been a better choice. -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 Aug 06 03:02:28 1996 Received: from necom830.hpcl.titech.ac.jp by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Aug 1996 00:00:49 -0700 From: Masataka Ohta Message-Id: <199608060700.QAA05755@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA05755; Tue, 6 Aug 1996 16:00:11 +0900 Subject: Re: Rat, Vat, and Linux To: hasty@rah.star-gate.com (Amancio Hasty) Date: Tue, 6 Aug 96 16:00:10 JST Cc: crawdad@FNAL.GOV, rem-conf@es.net In-Reply-To: <199608052156.OAA03547@rah.star-gate.com>; from "Amancio Hasty" at Aug 5, 96 2:56 pm X-Mailer: ELM [version 2.3 PL11] > >From The Desk Of Matt Crawford : > > I believe you haven't given this enough thought. The end-of-spurt > > marker indicates that the sound following the mark need not be > > Those darn semantics... Okay, the problem to solve is how to > keep two vat clients in sync when we know that the clocks are not > accurate. Additionally, for interactive sessions if silence suppression > is not used to keep the duration of the playback buffer relatively small. It's an issue of resampling. For the perfect resampling upto the limit of sampling theorem, use a sinc (NOT sine) function. In practice, linear interporation is often enough. For example, if you have two sample values of 0 at time 10 and 5 at time 20, approximated resample value at time 15 could be 2.5. If the resampling frequency is significantly lower (more than 5%, for example) than the original frequency, filtering before the resampling will be necessary to prevent aliasing. > vat still needs work, A.H. But, it's a lot easier than many compression algorithms. Masataka Ohta From rem-conf-request@es.net Tue Aug 06 10:54:52 1996 Received: from mercury.Sun.COM by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Aug 1996 07:54:17 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA16779; Tue, 6 Aug 1996 07:54:16 -0700 Received: from rebma. by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA17087; Tue, 6 Aug 1996 07:54:13 -0700 Received: by rebma. (5.x/SMI-SVR4) id AA24088; Tue, 6 Aug 1996 07:52:19 -0700 Date: Tue, 6 Aug 1996 07:52:19 -0700 From: hoffman@rebma.Eng.Sun.COM (Don Hoffman) Message-Id: <9608061452.AA24088@rebma.> To: rem-conf@es.net Subject: MBONE session annoucement: Sunergy 22 - THE FUTURE OF COMPUTING ARCHITECTURES X-Sun-Charset: US-ASCII The following program will be multicast on MBONE: "THE FUTURE OF COMPUTING ARCHITECTURES" THURSDAY, August 8, 1996 8:30 am - 9:30 am (Pacific Daylight Time) (15:30 - 16:30 GMT) Sunergy 22 examines how existing computer architectures meet user requirements- from uniprocessors to SMP and MPP- then discusses what additional resources might be needed to address emerging system requirements. In an interdependent 'ecosystem' of computing technologies and architectures, where will these new resources be found? GUEST LIST: JOHN GAGE (host), Director of the Science Office, Sun Microsystems Computer Company DR. GREG PAPADOPOULOS, Vice President and Chief Technology Officer, Sun Microsystems Computer Company DAVID A PATTERSON, Professor of Computer Science, University of California, Berkeley. GUY STEELE, Distinguished Engineer, Sun Microsystems, Inc. URL: http://www.sun.com/sunergy/ Audio format will be RTP/DVI and video will be H.261. The session is announced in sdr. Please let hoffman@eng.sun.com know if there are any problems or conflicts. Thanks. Don Hoffman Sun Microsystems, Inc. email - hoffman@eng.sun.com, phone - +1 503 297 1580, fax - +1 503 297 2880 From rem-conf-request@es.net Tue Aug 06 12:58:56 1996 Received: from megamegs.decisive.com by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Aug 1996 05:20:41 -0700 Received: from jamie.decisive.com ([206.171.43.189]) by megamegs.decisive.com (post.office MTA v1.9.3 ID# 0-12889) with SMTP id AAA122 for ; Tue, 6 Aug 1996 04:36:41 -0700 Received: by jamie.decisive.com with Microsoft Mail id <01BB8357.27E43040@jamie.decisive.com>; Tue, 6 Aug 1996 05:21:43 -0700 Message-ID: <01BB8357.27E43040@jamie.decisive.com> From: feedback@decisive.com (Network Education Center) To: "'rem-conf@es.net'" Subject: Survey on Continuing Education for Network Computing Professionals Date: Mon, 5 Aug 1996 18:36:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This survey is on behalf of an education center dedicated to the needs = of network computing professionals. We are asking your input to help us = create better education/training programs for you and your company. Your = responses will be completely confidential. If we receive your completed survey by Monday, August 12, 1996, we'll = automatically enter you in a contest for a prize of $1,000; one winner = will be chosen from among those who complete the survey. Thank you in = advance for your help.=20 (Authentication marker -- ~3%e%INTCADX%8%1%1537%5CTJVlfE%62961& -- do = not remove.)=20 To respond, create a reply e-mail message that contains the survey. = Some e-mail systems require you to manually copy and paste the survey = into your reply. Make sure the reply contains the *entire* = authentication marker, including what looks like garbage. To answer a question, type an x between the brackets, like this: [ x ]. = For fill-in-the-blanks, type between the brackets like this: [ your = response ]. Please make no other changes to this survey. 1. If for any reason you do NOT want to be contacted in the future via = e-mail, please indicate after the first question by placing an "x" = within the brackets. You will be omitted from future e-mail surveys. [ ] a) Please omit me from future e-mail surveys. 2. What is your company's PRIMARY industry or business? Choose one: [ ] a) Aerospace [ ] b) Communications carrier (telco, broadband, internet) [ ] c) Financial services [ ] d) Healthcare [ ] e) Manufacturing: computer/software [ ] f) Manufacturing: non-computer [ ] g) Government/military [ ] h) Publishing/media/advertising/public relations [ ] i) Transportation/utilities [ ] j) Wholesale/retail: non-computer [ ] k) Education [ ] l) Entertainment [ ] m) Computer reseller/retailer/VAR [ ] n) Systems integration/consulting [ ] o) Other, please specify... [ ] 3. What is your job function? Choose one: [ ] a) IS/MIS/Data processing [ ] b) LAN/network systems [ ] c) Internet/Web [ ] d) Intranet (in-TRA-net) [ ] e) Data communications/telecommunications [ ] f) PC/microcomputer/information center [ ] g) Systems analyst/applications development [ ] h) Systems engineer/integration [ ] i) Other computer-related, please specify... [ ] [ ] j) Executive/corporate office [ ] k) Financial/accounting [ ] l) Engineering/R&D [ ] m) Sales/marketing [ ] n) Other administrative, please specify... [ ] [ ] o) Consulting (computer related) [ ] p) Training/education [ ] q) Other professional, please specify... [ ] 4. Please check the statements below that describe your involvement = with networks. Choose all that apply: [ ] a) I manage networks. [ ] b) I design networks. [ ] c) I install networks. [ ] d) I troubleshoot/fix networks. [ ] e) I train or support network users. [ ] f) I initiate the evaluation of new network technologies. [ ] g) I evaluate or specify brands of network products. [ ] h) I ensure that networks meet specific business or = organizational objectives. 5. What is the scope of your involvement with networking in your = organization? Choose one: [ ] a) Entire organization or enterprise [ ] b) Entire work location [ ] c) Multiple departments at more than one location [ ] d) For a single department only [ ] e) Other 6. How many servers do you have installed in your organization? Choose one: [ ] a) Over 50 [ ] b) 10 to 49 [ ] c) 1 to 9 [ ] d) None 7. How many LANS do you have installed in your organization? Choose one: [ ] a) Over 25 [ ] b) 5 to 24 [ ] c) 1 to 4 [ ] d) None 8. How many microcomputers/workstations are connected to LANS in your = organization? Choose one: [ ] a) 500 or more [ ] b) 25 to 499 [ ] c) 1 to 24 [ ] d) None 9. How many employees do you supervise? Choose one: [ ] a) Up to 3 people [ ] b) 4 to 10 people [ ] c) More than 10 people [ ] d) None 10. Do you yourself have responsibility for networking = education/training provided to employees in your company? Choose one: [ ] a) Yes [ ] b) No [ ] c) Don't know 11. What is the annual budget for education/training for yourself and = those you supervise? Please enter the amount within the following brackets. [ ] 12. During the last 12 months, where did you or those you supervise = receive education/training for networking? Choose all that apply: [ ] a) In-house [ ] b) University/college [ ] c) Seminars [ ] d) Internet [ ] e) Other [ ] f) No education/training on networking was received NOW WE WANT YOUR OPINIONS ABOUT A POSSIBLE EDUCATION CURRICULUM ON = NETWORKING TECHNOLOGIES. For each of the following 10 course = descriptions, please indicate your level of interest. 13. A Network Technologies course covering circuits and fibers; = modulation and modems; LANs; WANs; frames; cell switching; wireless; = satellites; connection-oriented and connectionless service; = characteristics of each technology; addressing; media access; = comparisons. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 14. A Network Interconnection and Internetworking course covering = interconnection technologies; repeaters, bridges, and routers; internet = addressing; address binding; datagram forwarding; techniques to = accomodate heterogeneity (e.g. encapsulation and fragmentation). Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 15. A Network Protocols and Protocol Design course covering protocol = layering; problems protocols solve; loss, reordering, corruption, = congestion, duplication, and replay; techniques such as framing, = checksumming, sliding window, and retransmission; focus on the transport = layer, but cover other layers. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 16. A Routing and Routing Protocols course covering packet forwarding; = route propagation; vector-distance and link-state algorithms; spanning = tree. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 17. A Distributed Programming and Applications course covering = client-server paradigm; socket API; middleware (e.g. RPC and CORBA); = building a server; multithread server execution; protection and = authorization; example applications. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 18. A Network and Protocol Performance Evaluation course covering = throughput and delay; measuring and tuning protocols; instrumentation of = protocol stacks; traffic analysis; self-similar behavior. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 19. A Networking and Protocol Support for Multimedia Applications = course covering high-speed networks; resource allocation and performance = guarantees; protocols for audio and video; techniques such as = compression and delayed playback. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 20. An Advanced Server Design and Implementation course covering = implementation of concurrent, parallel servers; large-scale designs; = proxy servers (e.g., SLIRP); techniques such as buffering, replication, = caching, and application gateways. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 21. An Advanced Routing course covering policy-based routing; = multicast; mobility; inter- and intra-layer encapsulation; longest = prefix forwarding table lookup algorithms; virtual LANS. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 22. An Advanced Network Applications course covering EDI; electronic = commerce; advanced Web techniques (e.g. Java). Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 23. What would your level of interest be in taking a group of these = courses as a coordinated curriculum? Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting THINKING ABOUT THE CHARACTERISTICS AND BENEFITS OF DIFFERENT TYPES OF = EDUCATION PROGRAMS that could be made available for networking = technologies, please indicate which of the following would be important = to you. 24. A course curriculum leads to an advanced college degree. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 25. Each course generates a document of professional certification. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 26. Course curriculum leads to an overall certification. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 27. Course is available at your place of work. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 28. Course is available at a local university or college campus. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 29. Courses available at an industry event you already attend. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 30. Courses conducted by an advanced educational institute staffed by = networking experts. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 31. A core curriculum of a specified number of courses that would = follow a building educational sequence. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 32. A concentrated face-to-face education program conducted over = consecutive days. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 33. Ability to take class lessons, labs and tests over the Internet = >from your desktop. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 34. What other thoughts do you have concerning what could be done to = improve educational or training programs on networking technologies? Please write within the brackets. [ ] 35. How many years have you been professionally involved in computing? Choose one: [ ] a) Less than 2 years [ ] b) 2 to 4 years [ ] c) 5 to 10 years [ ] d) More than 10 years 36. Which of the following ranges includes your age? Choose one: [ ] a) 18 to 34 [ ] b) 35 to 44 [ ] c) 45 to 54 [ ] d) 55 and older 37. Which of the following represents your highest level of education? Choose one: [ ] a) Attended high school [ ] b) Graduated high school [ ] c) Attended college [ ] d) Bachelor's degree [ ] e) Master's degree [ ] f) Doctorate degree 38. What do you estimate your total household income was last year? = (Please estimate total income for everyone in your household, including = salaries, wages, bonuses, interest, dividends, etc.) Choose one: [ ] a) Less than $15,000 [ ] b) $15,000 to $24,999 [ ] c) $25,000 to $34,999 [ ] d) $35,000 to $49,999 [ ] e) $50,000 to $74,999 [ ] f) $75,000 to $99,999 [ ] g) $100,000 to $149,999 [ ] h) $150,000 or more [ ] i) Don't know Thank you for participating in this survey. From rem-conf-request@es.net Tue Aug 06 14:56:17 1996 Received: from scs.USNA.NAVY.MIL (actually csb.scs.usna.navy.mil) by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Aug 1996 11:55:39 -0700 Received: from douglas.scs.usna.navy.mil by scs.USNA.NAVY.MIL (SMI-8.6/SMI-SVR4) id OAA05679; Tue, 6 Aug 1996 14:49:50 -0400 Received: by douglas.scs.usna.navy.mil (SMI-8.6/SMI-SVR4) id OAA02895; Tue, 6 Aug 1996 14:34:46 -0400 Date: Tue, 6 Aug 1996 14:34:46 -0400 From: eun@scs.USNA.NAVY.MIL (E.K. Park x36806) Message-Id: <199608061834.OAA02895@douglas.scs.usna.navy.mil> To: tccc@cs.umass.edu, dbworld@cs.wisc.edu, end2end-interest@isi.edu, f-troup@aurora.cis.upenn.edu, cost237-transport@comp.lancs.ac.uk, reres@laas.fr, hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca, rem-conf@es.net, sigmedia@bellcore.com, mobile-ip@Tadpole.Com, cellular@comnets.rwth-aachen.de, badri@cs.rutgers.edu, ieeetcpc@ccvm.sunysb.edu, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comswtc@gmu.edu, G_F_Wetzel@att.com, wolfson@ouri.eecs.uic.edu, bhumip@gte.com Subject: Re: ICCCN96 ADVANCE PROGRAM Cc: BLeiner@arpa.mil, bb@cs.purdue.edu, chiueh@cs.sunysb.edu, chlamtac@BCN.BU.EDU, danzig@pollux.usc.edu, dbarbara@bellcore.com, epitoura@cc.uoi.gr, grossman@uic.edu, hfk@research.att.com, imielins@cs.rutgers.edu, jimf@aro.ncren.net, liny@liny.csie.nctu.edu.tw, mhd@seas.smu.edu, ralonso@peanut.sarnoff.com, randy@cs.Berkeley.edu, sbz@cs.brown.edu, sharony@hazeltine.com, son@aic.hrl.hac.com, szabo@hit.bme.hu, wildman@arl.mil, wolfson@bert.eecs.uic.edu, yemini@cs.columbia.edu, yeyesha@cesdis.edu, ygz@aic.hrl.hac.com, eun@scs.USNA.NAVY.MIL Content-Type: X-sun-attachment ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 5 ICCCN96 advance program is enclosed for your information. Please distribute among your colleagues and friends. ICCCN96 ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: advance-prg.icccn96 X-Sun-Charset: us-ascii X-Sun-Content-Lines: 978 PRELIMINARY PROGRAM AND CALL FOR PARTICIPATION IC3N'96 5th International Conference on Computer Communications and Networks October 16 - 19, 1996 Double Tree Hotel, Rockville, Maryland, USA Sponsored* by DataTech and NASA. Technical Co-Sponsorship by IEEE Communication Society. In cooperation* with NSF, NIST, USL, USC Communication, IEEE Computer Society, and ACM. (* pending approval) Keynote Speakers: * Harry Rudin IBM Zurich * Shukri Wakid NIST ******************************************************************************** Tuesday, October 15 ******************************************************************************** 6:00-8:00pm Registration ******************************************************************************** Wednesday, October 16 ******************************************************************************** 7:30-8:30am Registration 8:30-8:45am Opening Session: Kia Makki (General Co-chair) David Lee (Program Co-chair) 8:45-9:45 Keynote Address: 9:45-10:00am Coffee Break 10:00-11:00am Two Parallel Sessions (1, 2) - ------------------------------------------------ Session 1: VIDEO Chair: 1. A quasi-static retrieval scheme for interactive VOD servers Senthil Sengodan and Victor O.K.Li (University of Southern California) 2.Modeling and Performance Evaluation of a Scalable Distributed Video Server Architecture for VBR MPEG Encoded Video Data Streams Jurgen Enssle (University of Stuttgart) Session 2: QOS AND PERFORMANCE Chair: 1. Multiparameter QoS admission control for ATM queues with Partial Buffer Sharing Mechanism Jelena Misic and Samuel T. Chanson (Hong Kong University of Science and Technology) 2. Dynamic Resource Allocation Based on Measured QoS Sanjeev Rampal, Douglas S. Reeves and Yannis Viniotis (IBM) 3. A Trace-Driven Simulation of an ATM Queueing System with Real Network Traffic Gilberto Mayor and John Silvester (University of Southern California) - ------------------------------------------------------------------------ 11:00-11:15am Coffee Break - ------------------------------- 11:15-12:45pm Two Parallel Sessions (3, 4) - ------------------------------------------------ Session 3: SYSTEM ANALYSIS Chair: 1. Toward Modular Verification of Communication Protocols Wuxu Peng and Kia Makki (Southwest Texas State University/University of Nevada, Las Vegas) 2. Incremental Conformance Testing using Lotos Specifications Richard H. Carver (George Mason University) 3. An Adaptive System-Level Diagnosis Approach for Chordal Ring Networks Sadato Yoden and Hiroshi Masuyama (Tottori University) - --------------------------------------------------------- Session 4: INTERNET PROTOCOLS Chair: 1. Increasing Demultiplexing Efficiency in TCP/IP Network Servers Joseph T. Dixon and Kenneth Calvert (Georgia Tech) 2. VCI Cache and Timeout Design for IP over ATM Hiroshi Saito (NTT) 3. DRRM: Dynamic Resource Reservation Manager Phyllis Schneck, Ellen Zegura and Karsten Schwan (Georgia Tech) - ------------------------------------------------------------------ 12:45-1:45pm Lunch - -------------------------------------------- 1:45-2:30pm Two Invited Talks: - ------------------------------------------------------------------------ 2:30-2:45pm Coffee Break - --------------------------------------------- 2:45-4:15 Two Parallel Sessions (5, 6) - ---------------------------------------------- Session 5: MULTICASTING Chair: 1. A Flexible Protocol Architecture for Multi-party Conferencing Sudhir Aggarwal and Sanjoy Paul (SUNY/Bell Labs) 2. Core Migration for Dynamic Multicast Routing Michael J. Donahoo and Ellen W. Zegura (Georgia Tech) 3. A Hardware Architecture for Gigabit Multicasting X. Chen, L.E. Moser and P.M. Melliar-Smith (University of California Santa Barbara) Session 6: FLOW CONTROL AND PERFORMANCE Chair: 1. Dynamic Rate Estimation/Allocation for Congestion Control in High-Speed LAN/MAN Internetworking B.J. Lee and J.W. Mark (University of Waterloo) 2. Modeling Stream Overflows for Circuit-Switched Communication Networks Ramesh Bhandari (Bell Labs) 3. Performance of a Symmetric Robust WDM Circuit-Switched Network with Token-Passing in Control Channel Samir A. Abd-Elmalak, Chintan Vaishnav and Anura P. Jayasumana (Colorado State University) - ------------------------------------------------------------------ 4:15-4:30pm Coffee Break - ------------------------------------------------------------------ 4:30-6:00pm Two Parallel Sessions (7, 8) - ------------------------------------------------- Session 7: ATM Chair: 1. Performance Modeling of Bursty ATM Networks W. Amos Tiao and Laxmi N. Bhuyan (Texas A&M University) 2. A Control Platform for ATM LAN Switching Systems Chan Park, Jin Oh Kim and Hyup Jong Kim (Electronics and Telecommunications Research Institute) 3. Performance Evaluation of Barrier Synchronization in ATM Networks Y.-j Tsai, Y. Huang and P.K. McKinley (Michigan State University) Session 8: BROADCASTING AND MULTIPLE SERVICES Chair: 1. Optimal Location of Broadcast Sources in Unreliable Tree Networks A.B. Stephens, David M. Lazoff and Yelena Yesha (The John Hopkins University) 2. Fast and Robust Broadcasting in Faulty Hypercubes Siu-Cheung Chau and Ada Wai-chee Fu (University of Lethbridge) 3. Realtime Connection Admission Control for Multiple Service Categories Masaki Aida Masahiko Nakamura (NTT) - --------------------------------------------------------------------- 6:30-8:00pm Conference Reception ******************************************************************************** Thursday, October 17 ******************************************************************************** 7:30-8:30am Registration 8:30-9:30am Keynote Address: 9:30-9:45am Coffee Break 9:45-10:45am Two Parallel Sessions (9, 10) - ------------------------------------------------ Session 9: VIDEO Chair: 1. Quantum: An Efficient Video-on-Demand System Koling Chang and H.T. Kung (Harvard University) 2. An ATM Service Architecture for the Transport of Adaptively Encoded Live Video Brett J. Vickers and Tatsuya Suda (University of California, Irvine) Session 10: NETWORK DESIGN AND ARCHITECTURE Chair: 1. A Scaleable Very Large ATM Switch Architecture for Bursty Traffic Paul Shipley and Madgy Bayoumi (University of Southwestern Louisiana) 2. An Embedded Real-Time Network: Ganglia Dayton Clark (Brooklyn College, CUNY) 3. TWDM Multihop Lightwave Networks Based on Generalized Kautz Digraph Peng-Jun Wan (Honeywell Technology Center) - ------------------------------------------------------------------- 10:45-11:00am Coffee Break ------------------------------------------------------------------ 11:00-12:30pm Two Parallel Sessions (11, 12) - ------------------------------------------------- Session 11: ROUTING Chair: 1. Best-Effort Bandwidth Reservation in High Speed LANs using Wormhole Routing Bruce Kwan, Po-Chi Hu, Nicholas Bambos and Leonard Kleinrock (University of California, Los Angeles) 2. A Delay Bounded Multicast Routing Algorithm in Wide Area Networks Ziaohua Jia and Kia Makki (City University of Hong Kong/University of Nevada, Las Vegas) 3. Switch-Borne Router for High Performance Packet Forwarding of Connectionless Traffic Fahad Hoymany and Daniel Mosse (University of Pittsburgh) Session 12: SCHEDULING Chair: 1. Optimal Transmission Schedules for Embeddings of the De Bruijn Graphs in an Optical Passive Star Network Fengo Cao and Al Borchers (University of Minnesota) 2. A Starvation-free Algorithm For Achieving 100% Throughput in an Input-Queued Switch Adisak Mekkittikul and Nick McKeown (Stanford University) 3. The Design and Evaluation of Connection Scheduling Algorithms for Cross - Connects Chunming Qiao and Luying Zhou (SUNY Buffalo) - ------------------------------------------------------------------------ 12:30-1:30pm Lunch - ------------------------------------------------------------------------ 1:30-2:50pm One Session (13) - ------------------------------------------------- Session 13: CONGESTION CONTROL AND SCHEDULING IN ATM Chair: 1. Improved Burst-Level Admission Control Schemes for ATM Networks W. Melody Moh, Usha Rajgopal and Asha Dinesh (San Jose State University) 2. An Approach to the Flow Control of Best-Effort Traffic in Integrated Services Networks Joy Kuri and Anurag Kumar (Ecole Polytechnique) 3. Multimedia Streams Synchronization By Intra- and Inter-Stream Distance Scheduling Lee Chuan Hu and Kwei-Jay Lin (University of California, Irvine) 4. A New Scheduling Algorithm for Congestion Control in ATM Network SangChoon Lee, HyonChol Kim, MinGoo Lee and Moon Ho Lee (Chonbuk National University) - --------------------------------------------------------------- Poster Session: 12:30pm-3:pm - --------------------------------------------------------------- 2:50-3:05pm Coffee Break - --------------------------------------------------------------- 3:05-4:25pm Two Parallel Sessions (14, 15) - ---------------------------------------------------- Session 14: MULTICASTING Chair: 1. The problem of multicast in mobile networks Kevin Brown and Suresh Singh (University of South Carolina) 2. Performance Study of Buffer Management with Two Classes of Service Under Multicast Traffic in ATM Switching Nodes Khalid H. Sheta and Mukesh Singhal (The Ohio State University) 3. A Lower Bound on the Expected Cost of Minimum-Delay Multicast Traffic in Regular Graphs Srini B. Tridandapani, Michael S. Borella and Biswanath Mukherjee (Iowa State University) 4. A QoS Guaranteed ATM Multicast Service in Supporting Selective Multimedia Data Transmission (National University of Singapore) - ------------------------------------------------------------------------- Session 15: TRAFFICE MANAGEMENT AND PERFORMANCE ANALYSIS Chair: 1. Performance and software Evaluation of the Modular TIP Communication System Stefan Bocking (Siemens AG) 2. Improving the Performance of Shared-buffer Multistage ATM Switches under Bursty Traffic using Backpressure and Pushout Simon Fong and Samar Singh (La Trobe University) 3. A Fast Method for Combining/Generating Synthetic Traffic Traces Exhibiting Short - and Long-Range Dependence Gam D. Nguyen (Naval Research Laboratory) - ------------------------------------------------------------------ 4:25-4:40pm Coffee Break - ------------------------------------------------------------------ 4:40-6:00pm Panel: Goverment Research Funding Chair: Aubrey M. Bush Deputy Divison Director Div. of Networking and Comm. Research and Infrastructure National Science Foundation - ------------------------------------------------------------------ 7:00-9:30pm Banquet Banquet Speaker: ******************************************************************************** Friday, October 18 ******************************************************************************** 7:30-8:30am Registration 8:30-9:30am Keynote Address: 9:30-9:45am Coffee Break - ----------------------------------------------- 9:45-11:05am Two Parallel Sessions (16, 17) - ----------------------------------------------- Session 16: TRAFFIC ADMISSION CONTROL AND ROUTING Chair: 1. A New Criterion for Route Selection in Communication Networks with Delay Sensitive Traffic Imrich Chlamtac, Andras Farago and Hongbiao Zhang (Boston University) 2. Leaky Bucket, Refreshed Bucket and Other Flow Admission Criteria Amal E.-Nahas, Kahalil M. Ahmed and Mohamed G. Gouda (UT Austin) 3. Scalable Router Configuration for the Internet Cengiz Alaettinoglu (ISI USC) 4. Multicast Routing in VP-based ATM Networks Ren-Hung Hwang and Hwa-Shing Huang (National Chung Cheng University) Session 17: PROTOCOLS Chair: 1. Protocol verification by leaping reachability analysis Hans van der Schoot and Hasan Ural (University of Ottawa) 2. Protocols for Photonic Local Area Networks Using Wavelength-Selective Couplers Adrian Grah and Terrence D. Todd (McMaster University) 3. All-Optical Slotted WDM Rings with Partially Tunable Tranmitters and Receivers M. Ajmone Marsan, A. Bianco and E. Gilbert Abos (Politecnico di Torino) 4. WFMTS: An Intelligent Networks Solution for Universal Personal Communications Hazem El-Gendy (EPEC) - ------------------------------------------------------------------------------ 11:05-11:20am Coffeee Break - ------------------------------------------------------------------------------ 11:20-12:45pm Two Parallel Sessions (18, 19) - ------------------------------------------------------------------------------ Session 18: VIDEO Chair: 1. A Multi-access Scheme for Wireless CDMA Networks Supporting Voice/Video/ Data Traffic Te-Kai Liu and John A. Sivester (University of Southern California) 2. Latency and Error Control in Live MPEG Video Communication over Computer Networks Ciro Aloisio Noronha Jr. and Feiling Jia (Optivision) 3. An Experiment in Establishment of Real-time Channels for Video on Demand Service Bo-Chao Cheng Alexander D. Stoyenko Thomas J. Marlowe Sanjoy Baruah 4. Performance Analysis of Call Admission Control Schemes for Integrated Video- Conferencing/Voice Broadband CDMA Communication Systems Chong Kheng Huat and Cheng Xun (Nanyang Technological University) Session 19: PROTOCOL DESIGN AND INTERFACE Chair: 1. Performance of TCP over ATM for various ABR Control Policies Carlos M.D. Pazos, Vincenzo Signore and Dirceu Cavendish Jr. (UCLA) 2. SubScrip - An efficient protocol for pay-per-view payments on the Internet Andreas Furche and Graham Wrightson (The University of New Castle) 3. A Novel SVC Mechanism for Call Connection and Control in ATM Networks R. R. Henry and P. J. Darby (University of Southwestern Louisiana) 4. Modelling and Performance Evaluation of a Message and Transaction Processing Protocol in a Distributed Mobile Environment L.H. Yeo, P. Steele and J. Han *************************************************************************** ICCCN'96 REGISTRATION FORM Oct. 16 -- 19, 1996, Double Tree Hotel, Rockville, MD, USA Please complete this form (TYPE or PRINT), and return with your payment to the address given below (Please copy this form for additional attendees). Your paper number, if any:__________________________ Your paper title, if any:_____________________________________________________ ______________________________________________________________________________ Paper authors:___________________________________________________________ Your First Name:_________________________ Last Name:_______________________________ Title (Dr/Mr/Ms/Prof.):_____ Position:________________________________________ Company/Univ.:___________________________________ Dept.:______________________ Address:______________________________________________________________________ City:_______________________________ State:_____ Zip/Postal Code:_____________ Country:______________________ Phone:_________________________________________ Fax:__________________________________E-mail:_________________________________ ============================================================================== ADVANCE (For AUTHORS by July 12, 1996. For regular attendees/non-authors by September 6, 1996): ICCCN96 Reg. Fee: IEEE Communic. Soc. ____Member($400.00) ____Non-Member($450.00) ___Student($300.00) Tutorial Reg. Fee: IEEE (each half day)____Member($200.00) ____Non-Member($230.00) ___Student($120.00) (each one day) ____Member($300.00) ____Non-Member($330.00) ___Student($220.00) ============================================================================== LATE/ONSITE (Received AFTER September 6, 1996): ICCCN96 Reg. Fee: IEEE ____Member($450.00) ____Non-Member($500.00) ___Student($350.00) Tutorial Reg. Fee: IEEE (each half day)____Member($250.00) ____Non-Member($280.00) ___Student($150.00) (each one day) ____Member($350.00) ____Non-Member($380.00) ___Student($250.00) - ------------------------------------------------------------------------------ ICCCN96 Reg. Fee : choose category $_______________ Tutorial Fee for each: choose category $_______________ Extra Page Charge:(US$150.00 per page) $_______________ Extra Conf. Reception Tickets: ($40/each) $_______________ Extra Conf. Banquet Tickets: ($50/each) $_______________ Extra copy of conf. proceedings: ($60/each) $_______________ Total Fees Enclosed: US$_____________________ ** Make check/money order payable to ICCCN96 ** Check method of payment: ___Check/money order (payable to ICCCN96) ___Company Purchase Order number:____________________ (we accept P.O only from companies in USA and late fee is applied to each P.O) Signature:________________________________________ Date:______________________ IEEE membership number (required for member rate):____________________________ * Please let us know if you are or not planning to attend any of the following events (please put "yes" or "no"): ___________________________________________________________ | | WILL ATTEND | WILL NOT ATTEND | |__________________________|_____________|_________________| |Oct. 16 Reception | | | |--------------------------|-------------|-----------------| |Oct. 17 Banquet | | | |--------------------------|-------------|-----------------| * At least ONE author per accepted paper (regular, short, or poster paper) should pre-register by above deadline (July 12, 1996), or the paper will be excluded from the proceedings. The proceedings will be published by IEEE. * The maximum length is 6 pages for regular paper, 4 pages for short paper, and one page for poster paper. Authors can buy at most 3 extra pages for regular paper at a cost of U.S. $150.00, at most 2 extra pages for short paper at a cost of U.S. $150.00 per page, and at most one extra page for poster paper at a cost of U.S. $150.00 (so total length limit is 9 pages for a regular paper, 6 pages for a short paper, and 2 pages for poster paper if you buy extra pages). * Send this two-page registration form with payment (in US Dollars ONLY and make checks or money order payable to "ICCCN96") to: Dr. EK Park ICCCN96 Computer Science Dept US Naval Academy 572 Holloway Road Annapolis, MD 21402 USA (410)293-6806; (410)293-2686(fax); eun@scs.usna.navy.mil by July 12, 1996 (pre-registration cut off date for authors). The conference registration fee covers the proceedings, conference reception, refreshments during the conference, and the dinner banquet. Additional reception ticket and banquet ticket can be purchased. * All payments must be in U.S. dollars. All checks or money orders from banks outside the United States should be cashable at a branch of that bank in the United States or at any U.S. bank. If you send us check or money order, it should have complete "micro encoding line" at the bottom of it (ask your bank about this). You can also send Traveler's check of American Express or Visa or MasterCard (be sure that you sign each check and make it payable to "ICCCN96"). We accept purchase orders from U.S. organizations only and late fees are applied to purchase orders. We DO NOT accept any other form of payments (no credit cards). You are responsible for paying fees to get the check or money order. Student rate attendees must have proper ID. * ICCCN96 will be held at: Double Tree Hotel 1750 Rockville Pike Rockville, Maryland 20852 USA Telephone: (301) 468-1100; (301) 468-0308(fax) Room Rate: $105.00. All room rates are net per room, per night, single or double occupancy plus taxes. Individuals to make their own reservations by calling 1-800-222-TREE (or 301-468-1100), and use the group code "GBZ" to receive fifth annual ICCCN96 conference group rate. Individuals are on their own for payment of room, tax and any incidental charges. All reservations must be made prior to the Cut-off date of Tuesday, September 17, 1996 at 12:01AM. All reservations must be guaranteed for late arrival by a valid credit card or an advance deposit of one night's room and tax. Check-in time is 3:00PM. * Acknowledgement of receipt of the registration form with payment will be sent out by e-mail only if you provide your e-mail address. Conference materials including receipts and proceedings can be picked up only at the registration desk on site. * Refund Policy: Paid registrants (non-authors) who cannot attend, and do not send a substitute, are entitled to a refund of paid fees (less a US$200.00 processing fee) if a request is received in writing on or before September 13, 1996. Registrants are liable for their full fees after that date (i.e., NO Refund will be made !!). All no-show registrations will be billed in full. Primary Author is responsible/liable for full registration fees for the accepted paper (regular, short, or poster paper) and at least one author per paper (if not the primary author) must register by the July 12, 1996 deadline (registration fee for each accepted paper will not be refunded at any cases). * If you have any questions contact appropriate person: on registrations (Dr. Park: eun@scs.usna.navy.mil); on technical programs (Program Chair Dr. David Lee: lee@research.att.com); on other conference related matters (General Chair Dr. Kia Makki: kia@koko.cs.unlv.edu). ********************************************************************* Tutorial #1 (Half Day, Afternoon, October 19th) "Multimedia Networking: Principles and Protocols." ================================================ Dr. Yoram Ofek T.J. Watson Research Center Room 36-203 P.O. Box 218 Yorktown Heights, N.Y. 10598 U.S.A. 914/945-3171 e-mail: ofek@watson.ibm.com TUTORIAL OVERVIEW: ================== The objective of this tutorial is to examine and study the current trends in high-speed multimedia networking tech- nologies - from rings and buses to arbitrary topology global networks. First, we examine the reasons why existing LANs are based on a single shared communication resource and a simple topology like a ring or a bus. Then we review what are the problems and various solutions of LANs with concur- rent access and spatial bandwidth reuse. The next step to- wards switch-based or arbitrary topology network (e.g., ATM, Internet) introduces major design challenges. We will exam- ine the possible routing and flow control solutions for in- tegrating bursty traffic with periodic real-time traffic for multimedia and parallel/distributed processing applications. SYLLABUS ======== o Part 1: Background - High performance LAN and WAN constraints: physical layout, bandwidth and propagation delay - Application support for real-time and bursty data processing (i.e., multimedia applications) o Part 2: Multimedia Network Evolution - From Ethernet and Token-ring to FDDI and DQDB - From single shared medium to spatial bandwidth reuse - From rings and buses to arbitrary topology: -- Why arbitrary topology? -- Problems and challenges of arbitrary topology o Part 3: Periodic Traffic Routing and Flow Control - Cell multiplexing in ATM with label swapping (VCI and VPI) - Synchronous traffic management on rings and buses - Rate control at the network's boundaries (e.g., leaky bucket) - Scheduling and traffic shaping with local timing (e.g., deadline scheduling, priority queueing) - Pseudo-isochronous cell switching for ATM - Time-driven priority on the global Internet with GPS (global positioning system) o Part 4: Bursty Traffic Routing and Flow Control - LAN emulation in ATM - Rate-based flow control in ATM - Credit-based flow control in ATM - "Hot potato" and deflection routing - Deflection with convergence routing o Part 5: Advances in Technology and Protocols - Complexity of packet switches - Reliable broadcast and multicast - Data support with reliable protocols: point-to-point and multicast - Real-time support with NTP, RTP and RTCP on the Internet - The H.3xx (e.g., H.323, H.324, H.310) multimedia protocols o Part 6: Discussion - Where are we? - Integration periodic and bursty traffic - Open issues COURSE LEVEL:Technical ============= WHO SHOULD ATTEND: ================== Engineers, scientists, network planners, high-performance multimedia LAN and WAN designers and users, protocol design- ers, Internet users and designers, computing system opera- tors and managers, designers of applications for multimedia networks, LAN and WAN marketing and sales people. INSTRUCTOR BIOGRAPHY: ===================== Yoram Ofek received his B.Sc. degree in electrical engi- neering from the Technion-Israel Institute of Technology in 1979, and his M.Sc. and Ph.D. degrees in electrical engi- neering from the University of Illinois-Urbana in 1985 and 1987, respectively. From 1979 to 1982 he was affiliated with RAFAEL, as a re- search engineer. During 1983-1984 he was at Fermi National Accelerator Laboratory, Batavia, Illinois, and from 1984 to 1986 he was with Gould Electronics, Urbana, Illinois. Since 1987 he has been a research staff member at the IBM T. J. Watson Research Center, Yorktown Heights, New York. His main research interests are access-control, routing and broadcast, flow-control and fairness in local and wide area networks, optical networks, distributed algorithms, parallel computer architectures, clock synchronization, self- stabilization, and fault tolerance. Dr. Ofek will the general chair of the 7th IEEE on Local and Metropolitan Area Networks, and he was the program Co- chairperson of the 6th IEEE Workshop on Local and Metropol- itan Area Networks. He has been on the program committees of INFOCOM and ICDCS, and a guest editor for IEEE Journal on Selected Areas in Communications} and Computer Communi- cations. In IBM Dr. Ofek has initiated the research activ- ities on ring LANs with spatial bandwidth reuse, switch-based LANs, and synchronization for ensuring quality of service (QoS) in the Internet an ATM networks. In partic- ular, and has been leading and managing the research activ- ities on the MetaRing and MetaNet architectures. - ---------------------------------------------------------------- Tutorial #2 (Half Day, Morning, October 19th) Wireless LANs ============== Prof. Dr. Adam Wolisz Technical University of Berlin 1. Introduction to wireless LANs: Motivation, goals, basic concepts Scenarios for the use of wireless LANs, examples of real applications edvantages, problems, short info on available products and standardization afforts (IEEE 802.11 and HIPERLAN) 2. Foundations of wireless transmission Radio vs. infrared, licenced vs. ISM band, propagation path losses, transmission disturbing and influencing factors, narrowband vs. spread spectrum, the variants of spread-spectrum transmission. Typical parameters of the individual solutions. 3. Introduction to multiple access protocols. Short intro to fixed assignment protocols, demand assignment protocols, and random access protocols. Random access with collision avoidance and random access with collission reduction - different approaches. Special requirements for MAC protocol in wireless: the hidden terminal, the exposed terminal scenarios. RTS/CTS approach to reduce the hidden terminal effect. 4. MAC protocols for wireless LANs DFWMAC selected by IEEE 802.11: The basic CSMA/CR inklusiv backoff variant, immediate acknowledgement, RTS/CTS addition, Point Coordination Function, achievable QoS. Some performance results (from simulation) HIPERLAN EY-NPMA protocol. Basic CSMA/CA approach. Priority Phase, Contention Resolution (Elimination and Yielding) Phase. The use of priority layers. Achievable QoS Other proprietary protocols 5. Power saving in WLANs The reason for and basic power consuming function - stand by for receive. Power saving in IEEE 802.11 and in HIPERLAN 6. Extending the range of a single picocell Two basic approaches: distribution system (e.G. IEEE 802.11) and forwarding (e.g. HIPERLAN). Discussion of requirements for both approaches. Solutions in emerging standards. 7. Terminal mobility Basic problems in terminal mobility. The Mobile IP approach. Mobility in IP v.6 8. Wireless access to ATM and wireless ATM Basic problems. Special MAC Protocols. Link Layer issues. Assuring the service continuity - Mobile Virtual Circuits. Research directions 9. End-to-end issues in interconnected fixed and wireless networks. The example: TCP over networks including wireless links. The influence of wireless links on the timer and window adaptation function. Ideas to overcome this influence: Indirect TCP, Snoop, fast retransmit, Link layer QoS enhancements. 10. The short survay of available products. The new features expected from the emerging standards. Short overview of research and development trends. - ------------------ Biography: Adam Wolisz received his Master Degree Dipl._Ing degree (1976) Dr. -Ing (1976) as well as habilitation (1983) from the Silesian Technical University in Gliwice. From 1972 till 1989 he was with the Institute of Complex Control Systems of the Polish Academy of Sciences (since 1978 as a head of a research laboratory) working initially in the area of real-time operating systems and computerised industrial control systems (1972-1979) and later in the area of computer networks and distributed systems with special impact on local area networks. In this period he was a frequent visitor of French and German Institutes and Universities. >From 1990-1993 he was with the Research Institute for Open Communication Systems of the German Research Center for Computer Science (GMD-FOKUS) in Berlin. Since mid 1993 he changed to the Technical University of Berlin where he is recently full professor of electrical engineering and computer science acting as deputy-director of the Institute for Telecommunication. Since 1.01.1995 he has been additionally nominated the head of the division "System Engineering and Performance" at GMD-FOKUS. His primary research interests are in architectures and protocols for local and metropolitan area networks with special impact on wireless LANs and wireless acess to high speed backbone as well as protocol engineering with impact on performance and Quality of Service aspects. He is author of 2 books and over 50 papers in technical journals and conference proceedings. The list of papers since 1990 can be found under http:// www_ift.ee.tu-berlin.de/wolisz/woliszpub.html - --------------------------------------------------------------- Tutorial #3 (Full Day, October 19th) ARCHITECTURE AND PERFORMANCE OF HIGH-SPEED ATM NETWORKS ======================================================= By K. Sohraby OBJECTIVE - --------- The objective of thise tutorial is to provide a thorough coverage of the basic principles of ATM networks. Both architecture and performance issues will be covered in detail. WHO SHOULD ATTEND - ----------------- This tutorial is intended for engineers and researchers in industry and academia who are interested in a thorough understanding of the of ATM networks. PREREQUISITES - ------------- Participants should have a some familiarity with the basic concepts of communication networks and probability theory. A review of these subjects as they apply to the course will be given. LECTURER - --------- KHOSROW SOHRABY received B.Eng and M.Eng degrees from the McGill University, Montreal, Canada in 1979 and 1981, respectively, and Ph.D degree in 1985 >from the University of Toronto, Toronto, Canada, all in Electrical Engineering. During 1984-1986 he was a research associate at the L'institute national de la recherche scientific - INRS Telecommunications, Montreal, Canada. In 1986 he joined AT&T Bell Laboratories, Holmdel, NJ as a Member of Technical Staff in the Teletraffic Theory and System Performance Analysis Department. In 1989 he joined IBM T.J. Watson Research Center, Yorktown Heights, NY as a Research Staff Member in the Communications Systems Department. While at IBM research, he was an adjunct faculty at Polytechnic University and Columbia University in the Department of Electrical Engineering teaching undergraduate and graduate courses in telecommunications. Since 1994 he has been a professor with the Computer Science Telecommunications Program at the University of Missouri-Kansas City. He is an active member of IEEE Communications Society and has served as the guest editor of number of special issues of the Journal of Selected Areas in Communications and Communications Magazine. He is a technical editor of Network Magazine, and member of editorial board of the International Journal of Wireless Networks. Dr. Sohraby has served on the technical program committee of many IEEE conferences and workshops. He was the technical program vice-chair of IEEE INFOCOM '94, technical program co-chair of IEEE INFOCOM '95 and the technical program chair of IEEE 10th Annual Workshop on Computer Communications to be held in September of 1995. COURSE OUTLINE Motivation (Why ATM?) Principles of ATM Transport Mechanism SDH and SONET ATM Adaptation Layer (AAL) Traffic Control and Resource Management Policing and Flow Control Traffic Modeling in ATM networks ON-OFF Sources and Their Properties Cell Loss Estimation in ATM Networks Switching in ATM Networks, Topological Design and Their Comparison End-to-End Jitter Calculus in ATM Networks Overview of ATM testbeds Open Issues - ---------------------------------------------------------------------- ------- End of Forwarded Message From rem-conf-request@es.net Tue Aug 06 19:30:45 1996 Received: from mail.arc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Aug 1996 16:30:15 -0700 Received: from [128.102.80.28] by mail.arc.nasa.gov (post.office MTA v1.9.3 ID# 0-13121) with SMTP id AAA16898 for ; Tue, 6 Aug 1996 16:32:21 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 1 (Highest) To: rem-conf@es.net From: mallard@mail.arc.nasa.gov (Mark Allard) Subject: Early Martian Life Briefing Date: Tue, 6 Aug 1996 16:32:21 -0700 An MBone broadcast will take place 10am(PDT)/1pm(EDT) where a team of NASA and Stanford scientists will discuss their findings showing strong circumstantial evidence of possible early Martian life including microfossil remains found in a Martian meteorite. The team's findings will be published in the August 16 issue of Science magazine. Apologies for the short notice. Contact me at 415-604-6145 if there is a conflict or issue related to the broadcast. M From rem-conf-request@es.net Tue Aug 06 23:18:18 1996 Received: from kasina.nlanr.net by osi-west.es.net with ESnet SMTP (PP); Tue, 6 Aug 1996 20:17:25 -0700 Received: by kasina.nlanr.net id UAA03022; Tue, 6 Aug 1996 20:17:22 -0700 From: kc@kasina.nlanr.net (k claffy) Message-Id: <199608070317.UAA03022@kasina.nlanr.net> Subject: NLANR web caching system experiences: Thursday, August 8th, 10am PDT To: rem-conf@es.net Date: Tue, 6 Aug 1996 20:17:22 -0700 (PDT) Cc: nlanr@nlanr.net X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Content-Type: text Content-Length: 1723 [we are going to try to broadcast this, equipment willing; we'll announce in sdr, audio rtp/dvi, video h.261] k San Diego Supercomputer Center 10:00 am, Thursday, August 8th Experiences and Observations on the NLANR Caching Infrastructure Duane Wessels, NLANR ABSTRACT World-Wide Web caches are designed to alleviate some of the problems due to the ever-increasing growth on the Internet. Caching is noticeably different than mirroring or replicating; It is mostly transparent to end users, and also, because it is client-driven, caches automatically adjust to accommodate popular objects based on user's access patterns. The National Science Foundation has provided funding to develop a prototype hierarchy of World-Wide Web caches for the United States. These caches have been in operation since November 1995. This paper describes our initial experiences and observations encountered while operating the caches. The caches run on DEC Alphaserver 1000 systems at each of five Supercomputer Center sites, plus FIX-West. The cache software was developed by researchers at the University of Southern California and the University of Colorado for the Harvest project. Many of the cache users are international sites, with especially heavy use coming from New Zealand, Germany, and the United Kingdom. Admittedly the SCCs are not in strategically optimal locations for root caches, since they would be more appropriate at large interconnects or at the boundaries of large back bones (like the Diginap). However, the SCC locations do allow us to benefit from the high-speed vBNS network that connects them, through which the root caches communicate with eachother. http://www.nlanr.net/Cache/ From rem-conf-request@es.net Wed Aug 07 12:14:37 1996 Received: from spain.it.earthlink.net (actually spain-c.it.earthlink.net) by osi-west.es.net with ESnet SMTP (PP); Wed, 7 Aug 1996 09:14:02 -0700 Received: from sauveur.earthlink.net (pool041.Max21.Los-Angeles.CA.DYNIP.ALTER.NET [153.37.33.105]) by spain.it.earthlink.net (8.7.5/8.7.3) with SMTP id JAA26155; Wed, 7 Aug 1996 09:10:43 -0700 (PDT) Message-ID: <3208BD56.3E1E@earthlink.net> Date: Wed, 07 Aug 1996 08:59:18 -0700 From: Louis lalonde X-Mailer: Mozilla 2.0 (Win95; U) MIME-Version: 1.0 To: mbone@isi.edu CC: rem-conf@es.net Subject: Multicasting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear MBoners, I am seeking current info on the status on mrouters, the future of the MBone and the 6-Bone, multicasting publishers and technology, and Prefab (the multimedia backbone). I have read several books (by Savetz and by New Riders) but are they outdated now? Are there other sources of info on multicasting and Prefab? Can anybody help me? Much appreciation for your consideration, LP in LA sauveur@earthlink.net From rem-conf-request@es.net Thu Aug 08 01:39:01 1996 Received: from mercury.Sun.COM by osi-west.es.net with ESnet SMTP (PP); Wed, 7 Aug 1996 22:38:28 -0700 Received: by mercury.Sun.COM (Sun.COM) id WAA26604; Wed, 7 Aug 1996 22:38:26 -0700 Received: from dahlgren.Eng.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA12007; Wed, 7 Aug 1996 22:38:24 -0700 Received: from coolant.Eng.Sun.COM by dahlgren.Eng.Sun.COM (5.x/SMI-SVR4) id AA26972; Wed, 7 Aug 1996 22:37:09 -0700 Received: from coolant by coolant.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id WAA02947; Wed, 7 Aug 1996 22:39:21 -0700 Message-Id: <199608080539.WAA02947@coolant.Eng.Sun.COM> To: rem-conf@es.net Subject: Re: vat/vic update period In-Reply-To: Your message of "Mon, 05 Aug 1996 21:24:46 PDT." Date: Wed, 07 Aug 1996 22:39:21 -0700 From: Steve Soule > > What is the current group participants information update period > > for vat and vic ? and is this period scaled up when the number > > of group participants grows.. ??! > > The answer to the second question is yes. For the other part of > the question, read section 6.2 of RFC1889 (RTP). Vic follows it > exactly (in fact, vic was used to develop & prototype the algorithm > in sec 6.2). A typical session is 128kb/s and the rtcp bw is 5% of > that or about 800 bytes/sec. Average report size is around 100 bytes > or about 8 reports/sec. aggregate. The minimum per-member report > interval is 5 sec so that tends to be the interval for 'small' sessions > (<40 members). Above this session size, the per-member interval > stretches out linearly proportional to the number of members. How does the program know the session bandwidth--in your example, 128 kb/s? I couldn't find this in RFC1889. From rem-conf-request@es.net Thu Aug 08 01:52:31 1996 Received: from mercury.Sun.COM by osi-west.es.net with ESnet SMTP (PP); Wed, 7 Aug 1996 22:51:51 -0700 Received: by mercury.Sun.COM (Sun.COM) id WAA28259; Wed, 7 Aug 1996 22:51:50 -0700 Received: from dahlgren.Eng.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA12683; Wed, 7 Aug 1996 22:51:47 -0700 Received: from coolant.Eng.Sun.COM by dahlgren.Eng.Sun.COM (5.x/SMI-SVR4) id AA27117; Wed, 7 Aug 1996 22:50:32 -0700 Received: from coolant by coolant.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id WAA03020; Wed, 7 Aug 1996 22:52:44 -0700 Message-Id: <199608080552.WAA03020@coolant.Eng.Sun.COM> To: rem-conf@es.net Subject: Re: vat/vic update period In-Reply-To: Your message of "Mon, 05 Aug 1996 21:24:46 PDT." Date: Wed, 07 Aug 1996 22:52:44 -0700 From: Steve Soule ... > the question, read section 6.2 of RFC1889 (RTP). Vic follows it > exactly (in fact, vic was used to develop & prototype the algorithm > in sec 6.2). A typical session is 128kb/s and the rtcp bw is 5% of > that or about 800 bytes/sec. Average report size is around 100 bytes ... How does the program know the session bandwidth--in your example, 128 kb/s? I couldn't find this in RFC1889. From rem-conf-request@es.net Fri Aug 09 16:14:46 1996 Received: from sol (actually sol.genie.uottawa.ca) by osi-west.es.net with ESnet SMTP (PP); Fri, 9 Aug 1996 13:13:57 -0700 Received: by sol (5.0/SMI-SVR4) id AA00420; Fri, 9 Aug 1996 16:13:27 +0500 Date: Fri, 9 Aug 1996 16:13:27 +0500 From: devi@sol.genie.uottawa.ca (Sridevi Palacharla) Message-Id: <9608092013.AA00420@sol> To: rem-conf@es.net Subject: MJPEG archives Content-Length: 125 Does anyone know if there are any archives of MJPEG files on the web, or any ftp site? Please let me know. thanx sridevi From rem-conf-request@es.net Sat Aug 10 04:28:43 1996 Received: from Lancelot.AlaskaOne.com (actually 207.14.69.65) by osi-west.es.net with ESnet SMTP (PP); Sat, 10 Aug 1996 01:28:06 -0700 Received: from travel (anc-cs-3-05.arctic.net [207.14.66.21]) by Lancelot.AlaskaOne.com (8.6.11/8.6.12) with SMTP id AAA15524; Sat, 10 Aug 1996 00:40:44 -0700 Received: by travel with Microsoft Mail id <01BB8652.7C54E7C0@travel>; Sat, 10 Aug 1996 00:25:51 -0800 Message-ID: <01BB8652.7C54E7C0@travel> From: Howard Goff To: "'rem-conf@es.net mailing list'" Cc: 'Howard Goff' Subject: RE: Date: Sat, 10 Aug 1996 00:25:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit subscribe From rem-conf-request@es.net Sun Aug 11 16:08:40 1996 Received: from dfw-ix3.ix.netcom.com by osi-west.es.net with ESnet SMTP (PP); Sun, 11 Aug 1996 13:07:57 -0700 Received: from (gvsi@sjx-ca39-04.ix.netcom.com [205.187.203.68]) by dfw-ix3.ix.netcom.com (8.6.13/8.6.12) with SMTP id NAA16793; Sun, 11 Aug 1996 13:07:48 -0700 Date: Sun, 11 Aug 1996 13:07:48 -0700 Message-Id: <199608112007.NAA16793@dfw-ix3.ix.netcom.com> From: gvsi@ix.netcom.com (Megan Kirst) Subject: TeleCon XVI To: videophone@es.net To: cu-seeme-l@cornell.edu To: rem-conf@es.net To: mbone@isi.net We have a number of free passes to the exhibits at the TeleCon XVI Conference at the Anaheim Convention Center in Anaheim California. The conference will be held on October 29, 30 and 31. This is the annual teleconferencing users conference and trade show. It's also the world's largest conference and trade show on videoconferencing and distance learning. If you would like a couple of free passes to the exhibits, please email us your name and mailing address. Our email address is GVSI@aol.com. If you have any questions please feel free to give me a call at 1-800-909-4874. Thank You Jim Hoover Global Videoconferencing Solutions, Inc. http://www.globalvideoconf.com/ From rem-conf-request@es.net Mon Aug 12 15:04:44 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Mon, 12 Aug 1996 12:04:12 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 12 Aug 1996 20:03:52 +0100 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: George Michaelson cc: rem-conf@es.net Subject: Re: sdr announcement cycle time. In-reply-to: Your message of "Tue, 06 Aug 96 13:58:09 +0900." <29356.839303889@connect.com.au> Date: Mon, 12 Aug 96 20:03:50 +0100 Message-ID: <6702.839876630@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >We find locally that the sdr session reporting is inadequate even for very >small groups of people. the period over which individuals come online and >expect to find a fresh sdr primed with details is very large, and close >to the begin time of a booked slot, the frequency of announcements should >rise to at least 1 every 10-15 seconds. For a long time now, there's been a plan (and some unfinished code) to allow a local sdr-server to proxy cache for local sdrs. This would mean that on sdr startup, you get a complete download of current sessions from the cache rather than having to wait for the announcements from the original source - the SAP draft in ftp://ftp.isi.edu/confctrl/docs/ specifically allows for such caches even with encrypted session announcements, but isn't implemented yet. The proxy should then also be able to make proxy announcements for you when you quit sdr so you don't need a GUI running to keep a session announced. >The behaviour of the entire system (sdr/vat/wb etc) when details of sessions >change and users are bound inside the tools is also a problem. Bugs in sdr >cause important details of announced sessions to change (like addresses and >ttls) and rendesvous across multiple ttl multiple address sessions is almost >impossible. If the sdr back-end protocol included some kind of "re-bind now" >message this would definately help. As you say, there have been a number of bugs in the UI resulting in unnecessary address reallocation - I believe these are now fixed (in sdr 2.2a20), so the problem should be considerably lessened. The problem with a re-bind is that SAP is only reliable when viewed over long timescales - you could find that due to loss, some of the members of a session rebind earlier than others, which could be very confusing. If sdr kept track of which apps it had started and produced a popup warning if it saw an address/port change in a session for which it still has apps running, perhaps this would be sufficient and less confusing? Mark From rem-conf-request@es.net Mon Aug 12 15:47:51 1996 Received: from tis-mail.thepoint.net (actually tis-backup.thepoint.net) by osi-west.es.net with ESnet SMTP (PP); Mon, 12 Aug 1996 12:47:17 -0700 Received: by tis-mail.thepoint.net with Microsoft Exchange (IMC 4.0.837.3) id <01BB8865.85812B50@tis-mail.thepoint.net>; Mon, 12 Aug 1996 15:47:09 -0400 Message-ID: From: Arlie Davis To: 'Mark Handley' Cc: "'rem-conf@es.net'" Subject: RE: sdr announcement cycle time. Date: Mon, 12 Aug 1996 15:36:18 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In case anyone is interested, I am currently implementing a proxy server that does exactly what Mark describes. It is implemented as a Windows NT service. It is not yet ready for even a test release, but if you have any comments, feel free to throw them at me. -- arlie >---------- >From: Mark Handley[SMTP:M.Handley@cs.ucl.ac.uk] >Sent: Monday, August 12, 1996 3:03 PM >To: George Michaelson >Cc: rem-conf@es.net >Subject: Re: sdr announcement cycle time. > >For a long time now, there's been a plan (and some unfinished code) to >allow a local sdr-server to proxy cache for local sdrs. This would >mean that on sdr startup, you get a complete download of current >sessions from the cache rather than having to wait for the >announcements from the original source - the SAP draft in >ftp://ftp.isi.edu/confctrl/docs/ specifically allows for such caches >even with encrypted session announcements, but isn't implemented yet. > >The proxy should then also be able to make proxy announcements for you >when you quit sdr so you don't need a GUI running to keep a session >announced. > > From rem-conf-request@es.net Mon Aug 12 15:59:02 1996 Received: from mercenary.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Mon, 12 Aug 1996 12:58:22 -0700 Received: from mercenary.CS.Berkeley.EDU (elan@localhost) by mercenary.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id MAA13350 for ; Mon, 12 Aug 1996 12:57:45 -0700 From: Elan Amir Message-Id: <199608121957.MAA13350@mercenary.CS.Berkeley.EDU> X-URL: http://www.cs.berkeley.edu/~elan To: rem-conf@es.net Subject: A Map of the Mbone Date: Mon, 12 Aug 1996 12:57:45 -0700 A pointer that might interest some of you. I have produced a map of the MBone by crawling the mbone and establishing a connectivity graph from the mrouter routing tables. The graph was then embedded using a network embedding tool. The results, while not perfect, are quite interesting as yet another visualization of the MBone. The size of the map is ~1400 mrouters. You can check it out at http://www.cs.berkeley.edu/~elan/mbone.html. Be aware that the gif of the map is quite large (2125x2106) so it will cause your machine to thrash if you do not have have sufficient memory (~64MB). -- Elan From rem-conf-request@es.net Mon Aug 12 18:48:35 1996 Received: from broon.off.connect.com.au by osi-west.es.net with ESnet SMTP (PP); Mon, 12 Aug 1996 15:47:31 -0700 Received: from connect.com.au (ggm@localhost) by broon.off.connect.com.au with ESMTP id IAA25879 (8.7.4/IDA-1.6); Tue, 13 Aug 1996 08:47:19 +1000 (EST) X-Authentication-Warning: broon.off.connect.com.au: ggm owned process doing -bs To: Mark Handley cc: rem-conf@es.net Subject: Re: sdr announcement cycle time. In-reply-to: Your message of "Mon, 12 Aug 1996 20:03:50 +0100." <6702.839876630@cs.ucl.ac.uk> Date: Tue, 13 Aug 1996 08:47:17 +1000 Message-ID: <25877.839890037@connect.com.au> From: George Michaelson For a long time now, there's been a plan (and some unfinished code) to allow a local sdr-server to proxy cache for local sdrs. If the process becomes sdr starts sdr contacts local cache on | address fetches current state sdr shows known sessions then yes, this would be fine. the cache introduces some issues wrt ownership of sessions. I can forsee a need for strong authentication to ensure the cache can hold secure sessions in a private manner and not give out ownership by mistake. If sdr kept track of which apps it had started and produced a popup warning if it saw an address/port change in a session for which it still has apps running, perhaps this would be sufficient and less confusing? I think that too would go a long way to helping. The human factors of trying to round up the lost sheep are proving very annoying! -George -- George Michaelson | connect.com.au pty/ltd Email: ggm@connect.com.au | c/o AAPT, Phone: +61 7 3834 9976 | level 8, the Riverside Centre, Fax: +61 7 3834 9908 | 123 Eagle St, Brisbane QLD 4000 From rem-conf-request@es.net Mon Aug 12 18:53:58 1996 Received: from broon.off.connect.com.au by osi-west.es.net with ESnet SMTP (PP); Mon, 12 Aug 1996 15:52:53 -0700 Received: from connect.com.au (ggm@localhost) by broon.off.connect.com.au with ESMTP id IAA25934 (8.7.4/IDA-1.6); Tue, 13 Aug 1996 08:52:20 +1000 (EST) X-Authentication-Warning: broon.off.connect.com.au: ggm owned process doing -bs To: Arlie Davis cc: 'Mark Handley' , "'rem-conf@es.net'" Subject: Re: sdr announcement cycle time. In-reply-to: Your message of "Mon, 12 Aug 1996 15:36:18 -0400." Date: Tue, 13 Aug 1996 08:51:49 +1000 Message-ID: <25917.839890309@connect.com.au> From: George Michaelson In case anyone is interested, I am currently implementing a proxy server that does exactly what Mark describes. It is implemented as a Windows NT service. It is not yet ready for even a test release, but if you have any comments, feel free to throw them at me. Does NT use primitives to access IP which map cleanly back into a unix daemon model? -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 Wed Aug 14 14:39:12 1996 Received: from ihgw2.att.com by osi-west.es.net with ESnet SMTP (PP); Wed, 14 Aug 1996 11:38:31 -0700 Cc: rem-conf@es.net, mrc@big.att.com, glenn@big.att.com, bgh@big.att.com Received: from big.att.com by ihig2.att.att.com (SMI-8.6/EMS-1.2 sol2) id NAA22264; Wed, 14 Aug 1996 13:32:37 -0500 Received: from march (march.research.att.com [135.16.210.57]) by big.att.com (8.7.5/8.7.3) with SMTP id OAA08987; Wed, 14 Aug 1996 14:34:59 -0400 (EDT) Sender: mrc@big.att.com Message-ID: <32121C61.41C67EA6@att.com> Date: Wed, 14 Aug 1996 14:35:13 -0400 From: "M. Reha Civanlar" Organization: AT&T Research X-Mailer: Mozilla 3.0b5aGold (X11; I; SunOS 4.1.3 sun4m) MIME-Version: 1.0 To: casner@precept.com Original-CC: rem-conf@es.net, mrc@big.att.com, glenn@big.att.com, bgh@big.att.com Subject: Re: A new payload type for ligth-weight bundled MPEG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit As promised, we prepared an Internet draft describing a new RTP payload for bundled MPEG: draft-civanlar-bmeg-00.txt which can be found in the usual location for the Internet drafts. I will appreciate receiving your comments/suggestions. -- M. Reha Civanlar AT&T Labs-Research 101 Crawfords Crnr. Rd., 4C520 Holmdel, NJ 07733-3030 Ph: (908) 949 6705 Fax: (908) 949 3697 From rem-conf-request@es.net Thu Aug 15 10:56:00 1996 Received: from ns.gte.com by osi-west.es.net with ESnet SMTP (PP); Thu, 15 Aug 1996 07:55:27 -0700 Original-Received: from [132.197.144.52] by ns.gte.com (8.7.5/) PP-warning: Illegal Received field on preceding line Date: Thu, 15 Aug 1996 10:49:54 -0400 (EDT) X-Sender: bk00@pophost.gte.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: enternet@bbn.com, itc@fokus.gmd.de, tccc@cs.umass.edu, dbworld@cs.wisc.edu, end2end-interest@isi.edu, f-troup@aurora.cis.upenn.edu, cost237-transport@comp.lancs.ac.uk, reres@laas.fr, hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca, rem-conf@es.net, mobile-ip@Tadpole.Com, cellular@comnets.rwth-aachen.de, ieeetcpc@ccvm.sunysb.edu, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comswtc@gmu.edu From: bhumip@gte.com (Dr Bhumip Khasnabish +1-617-466-2080) Subject: ENM-97 CFP. Pls Distribute. Thanks. Cc: ahmadi@engn.uwindsor.ca, braudyb@aol.com, rlfike@aol.com, bran@silcom.com, just4net@aol.com, stanm@bellcore.com, pogran@bbn.com, vkb@mvgsf.mv.att.com, bhagavath@bell-labs.com, w2xd@mtnms.att.com, dnzuckerman@bell-labs.com, w2xd@mtnms.lucent.com, aidarous@bnr.ca, kjl@bellcore.com, bhumip@gte.com, sbw@ccrl.nj.nec.com, c.desmond@ieee.org, nkc@bellcore.com, Ron.Horn.0090874@nt.com, mouftah@eleceng.ee.queensu.ca, t.stevenson@ieee.org, christos@ece.miami.edu, saracco@cselt.stet.it, xrjo@atc.boeing.com, wz@prosun.first.gmd.de, hegering@lrz-muenchen.de, yoshida@netwk.ntt-at.co.jp, craig@bbn.com, yemini@cs.columbia.edu, lanworks@delphi.com, ahmed@ece.concordia.ca, sie@probe.att.com, knecht@mvuss.att.com, a.pakstas@ieee.org, mike@sce.carleton.ca, yang@trix.genie.uottawa.ca, rne@hybrid.com, daniel.heer@att.com, bumblis@mcc.com, rdantu@tddcae99.fnts.com, jamoussi@nortel.ca, bhumip@gte.com, scott_linke@aus.hp.com, pradeep@dstc.uts.edu.au, guthery@austin.sar.slb.com, paulcov@bnr.ca, mohan@ccmail.inet.com, lewis@ctron.com, clytle@sed.stel.com, bobchap@ibm.net, oliveira@eurecom.fr, sidou@eurecom.fr, labetoul@eurecom.fr, dotti@fokus.gmd.de, bk00@ns.gte.com The IEEE Enterprise Networking Mini-conference (ENM) will be held in Montreal, Canada on June 11 & 12, 1997. in conjunction with the ICC-97 (June 8-12, 1997). Details are available at: http://www.ieee.org/comsoc/ENM-97.html Thanks a lot, with all the best wishes and regards, --------------------------------------------------------------------- Dr. Bhumip Khasnabish, GTE Labs. Inc., Rm.4-292 Tel +1-617-466-2080 40 Sylvan Road, Fax +1-617-890-9320 Waltham MA 02254 Res +1-617-647-5356 U.S.A. E-Mail: bhumip@gte.com bhumip@acm.org ..................................................................... Web Page within GTE Labs: http://cnsmacic.gte.com/users/bhumip/ ===================================================================== From rem-conf-request@es.net Thu Aug 15 15:24:25 1996 Received: from rags.rutgers.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 15 Aug 1996 12:23:48 -0700 Received: (from badri@localhost) by rags.rutgers.edu (8.6.12+bestmx+oldruq+newsunq/8.6.12) id PAA25905; Thu, 15 Aug 1996 15:22:30 -0400 Date: Thu, 15 Aug 1996 15:22:30 -0400 From: Br Badrinath Message-Id: <199608151922.PAA25905@rags.rutgers.edu> To: ieeetcpc@ccvm.sunysb.edu, orcs-l%osuvm1.BITNET@searn.sunet.se, glynn@leland.stanford.edu, ietf-announce@cnri.reston.va.us, mobile-ip , f-troup@aurora.cis.upenn.edu, rem-conf-request@es.net, cost237-transport@comp.lancs.ac.uk, reres@laas.fr, hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca, rem-conf@es.net, sigmedia@bellcore.com, arpanet-bboard@mc.lcs.mit.edu, cnom@meatro.bellcore.com, globecom@signet.com.sig, ietf@isi.edu, tccc@cs.umass.edu Subject: Advanced Program, Mobicom96 ACM/IEEE Present MOBICOM'96 Advance Program The Second Annual International Conference on Mobile Computing and Networking November 10-12, 1996 Rye Hilton Rye, New York, USA ================================================================= | Sponsored by: | | | | ACM CESDIS NASA IEEE | | Sigmobile, Sigcomm, Sigmetrics, ComSoc | | Sigops, Sigact | ================================================================== TUTORIAL PROGRAM Sunday, November 10 8:30 A.M. to 5:00 P.M. All tutorials will be half-day tutorials (4 hours each). Tutorials I and II will be in the morning (8:30 am-- 12:30pm) T1 Disconnected Browsing : WWW & Mobile Computing Anupam Joshi, Purdue University T2 Air Interface Standards Li Fung Chang, Bellcore Tutorials III and IV will be in the afternoon (1:30 -5:30 pm) T3 Secure Mobile Communications Yacov Yacobi, Bellcore T4 Mobile Networking within the IETF Charlie Perkins, IBM Welcome Reception 7:00 P.M. to 9:00 P.M. Hosted by IBM ------------------------- MONDAY, NOVEMBER 11 8:45 A.M. Opening Remarks Keynote Address: DR. VICTOR B. LAWRENCE, DIRECTOR OF ADVANCED COMMUNICATIONS TECHNOLOGY, Bell Laboratories of Lucent Technologies (formerly AT&T Bell Laboratories) 10:00 A.M. Break 10:30 A.M. Technical Sessions ------------------------------------------------------------------ Session No. 1: Mobile and Wireless TCP/IP Chair: Jim Freebersyser, ARO * Low-loss TCP/IP Header Compression for Wireless Networks, M. Degermark, M. Engan, B. Nordgren, and S. Pink, Lulea University and the Swedish Institute of Computer Science, Sweden (Student Paper Award) * TCP Extensions for Space Communications, R.C. Durst, G.J. Miller, The MITRE Corporation, and E.J. Travis, Gemini Industries * Mobility Support in IPv6, C.E Perkins, IBM T.J. Watson Research Center, and D.B. Johnson, Carnegie Mellon University ------------------------------------------------------------------ 12:00 Noon Conference Lunch Luncheon Talk: Mobile Computing: Where's the Tofu? M. Satyanarayanan, CMU 1:45 P.M. Session No. 2: Mobility Management Chair: Ray Pickholz, GWU * Efficient and Flexible Location Management Techniques for Wireless Communication Systems, J. Jannink, D. Lam, N. Shivakumar, J. Widom, D.C. Cox, Stanford University * On Resource Discovery in Distributed Systems with Mobile Hosts, D. Awduche, A. Gaylord, and A. Ganz, University of Massachusetts, Amherst * Fast and Scalable Handoffs for Wireless Internetworks, R. Caceres, Bell Labs, Lucent Technologies and V.N. Padmanabhan, UC Berkeley ------------------------------------------------------------------ 3:15 P.M. Session No. 3: PANEL 1 "Software Architectures for Mobile Networks," Session Chair: Aurel Lazar, Columbia Univ. Participants: D. Raychaudhuri, NEC C&C Labs Andrew T. Campbell, Columbia University, Krishan Sabnani, Bell Labs, Arvind Krishna, IBM T.J. Watson Research Center, Louis-Francois Pau, Ericsson, Glenford Mapp, Olivetti. 4:30 P.M. BREAK 5:00 P.M. Session No. 4: Resource Allocation and Sharing Chair: Siamak S. Tabrizi, Rome Laboratory * Spectrum Sharing Under The Asynchronous UPCS Etiquette: The Performance Of Collocated Systems Under Heavy Load, I. Vukovic and J. McKown, Motorola Wireless Data Group * Dynamic Loadbalancing Strategies for Channel Assignment Using Selective Borrowing in Cellular Mobile Environments S.K. Das, S.K. Sen, and R. Jayaram, University of North Texas * Lossless Handover for Wireless ATM H. Mitts, H. Hansen, and J. Immonen, VTT Information Technology, Finland 7:00 - 9:00 Conference Dinner Banquet TUESDAY, NOVEMBER 12 ============================================================================= 8:30 A. M. Session No. 5: Mobile Applications Chair: Mahmoud Naghshineh, IBM * Rapid Prototyping of Mobile Context-Aware Applications: The Cyberguide Case Study S. Long, R. Kooper, G. Abowd and C. Atkeson, Georgia Institute of Technology * WebExpress: A System for Optimizing Web Browsing in a Wireless Environment B.C. Housel and D.B. Lindquist, IBM Corporation * Building Fault-Tolerant Mobile-Aware Applications using the Rover Toolkit, A.D. Joseph and M.F. Kaashoek, MIT ------------------------------------------------------------------ 10:00 A.M. Break 10:30 A.M. Session No. 6: Issues in Mobile Computing Chair: Rabinder Madan, ONR * A Dynamic Disk Spin-down Technique for Mobile Computing, D. Helmbold, D. Long, and B. Sherrod, UC Santa Cruz * Reducing Processor Power Consumption by Improving Processor Time Management in a Single-User Operating System J.R. Lorch and A.J. Smith, UC Berkeley * Security on the Move: Indirect Authentication using Kerberos A. Fox and S. Gribble, UC Berkeley ------------------------------------------------------------------ 12:00 P.M. Conference Lunch 1:45 P.M. Session No. 7: LAN, MAC, and ATM Chair: Kevin Mills, DARPA * Wireless ATM MAC Performance Evaluation: HIPERLAN Type 1 Versus Modified MDR, L. Nenonen, Nokia Research Center / Nokia Telecommunications, Finland, and J. Mikkonen, Nokia Mobile Phones, Finland * A Scalable Wireless Virtual LAN, Z. Liu, M. Veeraraghavan, and K.Y. Eng, Bell Labs, Lucent Technologies * Floor Acquisition Multiple Access with Collision Resolution, R. Garces and J.J. Garcia-Luna-Aceves, UC Santa Cruz 3:15 Break 3:45 Session No. 8: PANEL 2 "Multimedia Mobile Wireless Networks - is Anytime, Anywhere, Anything a Dream or a Reality," organized by Jacob Sharony, Hazeltine. Participants: Jim Freebersyser - ARO Kevin Mills - DARPA Ambatipudi Sastry - SRI Martha Steenstrup - BBN Bezalel Gavish - Vanderbilt University 5:15 PM Conference Adjourns =============================================================================== Mobicom'96 Tutorials November 10th All tutorials will be half-day tutorials (4 hours each). Tutorials I and II will be in the morning from 8:30 am -- 12:30pm Tutorials III and IV will be in the afternoon 1:30 pm -- 5:30 pm Tutorial I ---------------- Disconnected Browsing : WWW & Mobile Computing --------------------------------------------------- The objective of this tutorial will be to familiarize the audience with the basics as well as the state of the art in disconnected browsing. We use this term to describe both the general aspects of accessing distributed multimedia data from limited capability and bandwidth platforms, as well as the specifics of browsing the Web from mobile (wirelessly networked) computers. The issues involved here lead to challenging problems in research that need to be addressed by the community, as well as interesting practical systems that will be useful in everything from battlefield management, tele-medicine, and education, inter alia. We will begin the tutorial from a general overview of the challenges posed by mobile systems to a wide variety of computer science disciplines, such as networking, data management, user interfaces etc. We will describe how the problems in these areas affect disconnected information browsing. We will also provide a short overview of the Web -- http, html and Java. Using the web as an example, we will describe and analyze the issues involved in creating systems for disconnected browsing. These involve mobile client server and proxy-scion architectures, disconnection management, information fusion, cooperative information gathering and multimedia transformation. We will describe application scenario, and conclude with a critical review of systems, including those worked on by the instructor, such as InfoPad, SciencePad, Odyssey, and Milktruck. Instructor: Anupam Joshi is a (Visiting) Assistant Professor of Computer Sciences at Purdue University, from where he received a Ph.D. degree in Computer Science in 1993. His research interests span the broad areas of computational intelligence, distributed AI and Networked/Mobile computing. He works on using AI/CI techniques to help in the creation of Intelligent, Ubiquitous Problem Solving Environments. Allowing such systems to be accessible from mobile platforms is an important aspect of this work, and is supported by an NSF award to Profs. Houstis and Joshi. He is also the PI of a grant >from Intel which seeks to address related problems in disconnected browsing - mobile access to distributed data such as that on the Web. This effort collaborates with the work being done by Profs. Elmagarmid and Helal in multidatabases and mobile systems. His other interests include computational vision and computer mediated (distance) learning. For the last 2 semesters, he has taught a seminar course in mobile computing at Purdue, and received 5.0/5.0 on student evaluations. He is a member of IEEE, IEEE-CS, ACM and UPE. Tutorial II --------------- Air Interface Standards: An Overview -------------------------------------- In this tutorial, we will first give a brief descriptions of impairments of wireless link, possible mitigations schemes and their impact on wireless data communications. We will then discuss difference and features of the "high tier" system vs. the "low tier" system. High tier systems are designed for high mobility vehicular services. Typical characteristics of a high tier system are large base station antenna heights, high transmission power, large coverage area, etc. Low tier systems are targeted for low speed pedestrian and indoor usage. A low tier system uses small inexpensive base stations for pole or wall mounting with low transmit power. Wireless technologies designed to operate in these systems will be quite different. We will give an overview of several air interface standards (both U.S. and worldwide) designed for the emerging Personal Communications Services (PCS). Some are designed for high-tier (e.g. GSM/DCS1900, IS-95 CDMA, etc.) and some are for low-tier (e.g. PACS-Personal Access Communication System, PHS-Personal Handyphone System, DECT-Digital European Cordless Telephone) systems. In particular, we will focus on the data communication capabilities of the air interface standards. Instructor: Li Fung Chang received the B.S. degree from the National Taiwan Normal University in 1978 and the M.S., Ph.D. degrees from the University of Illinois in 1983 and 1985, respectively. She joined Bell Communications Research in August 1985 as a member of technical staff in Radio Research Division. She is now a director and project manager of broadband wireless program. Her research efforts and interests are mainly in the area of wireless communications. Her early research works involved in the application of channel coding for wireless digital radio communications system. She has worked on the ARQ protocols, architecture for wireless data communications; link level performance evaluations of TDMA (Time-Division Multiple Access), CDMA (Code-Division Multiple Access), FHMA (Frequency-Hopping Multiple Access) wireless communication systems; privacy/authentication for wireless digital radio communications system; and protocol designs and system performance evaluations of the PACS for TDD operations for in-building application. She is also involved in design and network architecture for the interoperability of the high mobility cellular system and low mobility PCS system. Currently, she manages a research group working on protocol design and network performance evaluation of PCS mobility management on ATM transport and mobile IP over ATM. Dr. Chang holds three US patents in the aforementioned areas, five pending patents and has numerous publications. She has given short courses in PCS at National Chiao-Tung Univ. Taiwan, 1992, and 1995, respectively. She is a senior member of IEEE, Phi Kappa Phi and Phi Tau Phi Chinese honor society. Currently, she is chair of the communication chapter, IEEE NJ Coast Section. Tutorial III -------------- Secure mobile communications ---------------------------------- This 3 hours tutorial is intended for general MS/EE engineers and does not assume prior knowledge of cryptography or system security. It will cover: 1. Basic cryptography: The Shannon Model; and modern (complexity based, public key) cryptography. 2. Requirements for mobile security. 3. Special techniques for low-cost terminals. 4. Digital payment mechanisms. 5. Standards. Instructor: Dr. Yacov Yacobi has a Ph.D. in EE from Technion, IIT. He was a Senior Scientist at the Mathematics and Cryptography Group at Bellcore until recently, and is now with Microsoft Corp. He is the author of over 30 published papers, and over 10 patents in Cryptography, and a member of the Editorial Boards of IEEE Personal Communication Magazine, and The Journal of Computer Security. TUTORIAL IV ------------------ Mobile Networking within the IETF ------------------------------------ Within the Internet Engineering Task Force (IETF) there are a number of development activities for protocols which are relevant to mobile networking. Included among them are mobile-IP, DHCP, PPP, mobile-IPv6, and the Service Location Protocol. A description of these efforts will be given, including protocol details, current status information, and clarifying their relationships. The tutorial will explain the details of the mobile-IP model, as well as the registration protocols and tunneling mechanisms. When mobile computers attach themselves to new networks within the Internet, they can use mobile-IP as a means to achieve seamless roaming -- transparently to application software. Using mobile-IP, a mobile client supplies information to a router, called its home agent, about its current whereabouts using a simple registration protocol. Once the basic operation has been shown, additional mechanisms will be described to avoid the need for routing packets through the (possibly distant) home agent, providing a faster route between mobile clients and their correspondents. The Dynamic Host Configuration Protocol (DHCP) will then be introduced and its usefulness for mobile users explained. After describing the basic DHCP client/server model, I'll apply it in some likely scenarios for mobile computing, and show the advantages and the disadvantages of using DHCP. Perhaps even more than static computers, mobile computers will be used by people uninterested in performing administrative duties, and I will describe the use of a new option for DHCP which allows the acquisition of IP addresses appropriately configured for use with the mobile-IP protocols. Having covered the basics of mobility for IP version 4, I will describe IP version 6 and its provisions for mobile computing. I'll give enough details about IPv6 to make the discussion self contained, and then describe in detail the mobility messages. Architectural differences between IPv4 and IPv6 mobility will be presented, and the requirements for IPv6 hosts, routers, and mobile nodes will be enumerated. Interactions between mobility for IPv6 and other parts of the IPv6 protocol suite (such as Neighbor Discovery) will also be described. A final description will be of the Service Location Protocol (SLP), designed to eliminate additional configuration requirements that otherwise might require manual configuration by the users. For instance, a user would often need to find out which local printers can handle Postscript output, and where local mount points can be found for local libraries and other support data. Instructor --------------------- Charles Perkins (perk@watson.ibm.com) is a research staff member at IBM T.J. Watson Research, investigating mobile and ad-hoc networking, resource discovery, and automatic configuration for mobile computers. He is serving as the document editor for the mobile-IP working group of the Internet Engineering Task Force (IETF), and serves on the editorial boards for ACM/IEEE Transactions on Networking, ACM Wireless Networks, and IEEE Personal Communications. Charles holds a B.A. in mathematics and a M.E.E. degree from Rice University, and a M.A. in mathematics from Columbia University. Mobicom96 Local Information Hotel/Accommodations The Rye Town HILTON Phone:+1 800 445 8667 699, Westchester Avenue or +1 914 939 6300 Rye Brook, NY 10573 Fax: +1 914 939 5328 The hotel offers a wide variety of complimentary amenities and services available for your use: -Resort complex set on 45 acres of beautifully landscaped countryside. -Indoor pool -Full Service Fitness Center -Year round tennis -Jacuzzis, spas, and saunas -Hair salon and barber shop on property -Two award winning restaurants -The Den Lounge - open daily w/nightly entertainment. -Convention Services department to assist in any special needs that may arise. To make reservations at the hotel, contact reservations by October 20, 1996. As an attendee to the MOBICOM Conference, your guest room rate is $110.00 per night, based on single or double occupancy. To make reservations, please call 1-800-HILTONS. Please be sure to identify yourself as being with the ACM MobiCom Conference in order to receive the special room rate. Transportation For those needing transportation via any of the major airports (JFK, LaGuardia, or Newark), MARK 1 Limousine Company provides the most affordable option. Reservations for this service should be made in advance by calling 1-800-309-7070. >FROM LAGUARDIA AIRPORT - Grand Central Parkway to Route 678 over Whitestone Bridge. Follow to Hutchinson River Parkway North to Exit 26 East (Westchester Avenue, Rye). Continue on Westchester Avenue counting 6 lights. Turn left at 6th light into hotel driveway. >FROM KENNEDY AIRPORT - Van Wyck Expressway North to Whitestone Expressway over Whitestone Bridge. Follow same directions from LaGuardia Airport. >FROM ROUTE 95, HEADING NORTH - Route 95 north to Exit 21. Rollow Route 287 West to Exit 10 (Webb Avenue, Bowman Avenue). Straight off the exit ramp to your second traffic light. Bear right onto Westchester Avenue. Proceed to your third traffic light and turn left at hotel entrance. >FROM ROUTE 95, HEADING SOUTH - Route 95 south to Exit 21 (in New York). Follow Route 287 West to exit 10 (Webb Avenue, Bowman Avenue). Follow above directions. >FROM NEW YORK CITY - West Side Highway to Henry Hudson Parkway to Saw Mill River Parkway. Follow to Cross County Parkway East. Proceed to Hutchinson River Parkway North and continue to Exit 26 East (Westchester Avenue, Rye). Follow above directions. >FROM TAPPAN ZEE BRIDGE - Route 287 East to Exit 10. Go straight off exit ramp through 4 lights. At the 4th light, make a left into hotel entrance. BY TRAIN - Transportation is available on the Metro-North Railroad line from New York City and Connecticut to the Rye Station. On-site registration On-site Registration will be available on Sunday, November 10th between 8:00 A. M. And 5:00 P.M. and 7:00 P.M. On Monday, November 11th it will be held between 8:00 A.M - 5:00 P. M. and on Tuesday, November 12th between 8:00 A. M. -- 12:00 Noon. ================================================================ Exhibits ======== We will be hosting a small number of novel hardware and software exhibits relevant to mobile computing. The exhibits may be research prototypes or commercial products. Interested parties should contact Peter Honeyman (honey@citi.umich.edu) to reserve space. For more Information Web Page:http://www.acm.org/sigmobile/conf/mobicom96/ E-mail: Badri@cs.rutgers.edu Publicity chair: Badrinath, B. R., Rutgers University Phone: 908-445-2082 Mobicom96 Registration Form Tutorials (Check each tutorial attending) [] T1 Disconnected Browsing : WWW & Mobile Computing [] T2 Air Interface Standards [] T3 Secure Mobile Communications [] T4 Mobile Networking within the IETF Early Late Registration Registration Before After 10/18/96 10/18/96 Fee for each Tutorial ACM Members: $180____ $225____ Non-members: $220____ $265____ Full-time students: $100____ $125____ Total fee for Tutorials _____ _______ Conference Registration* ACM Members: $320____ $370____ Non-members: $400____ $450____ Full-time students#: $125____ $155____ Extra Dinner Banquet: $55_____ $55_____ Extra Proceedings: $45_____ $45_____ *includes proceedings, sessions, reception, lunches and banquet #includes proceedings, sessions, reception and lunches Total Fees $________ $_________ Vegetarian Meals: Yes _____ No _______ ___________________________________________________________ Special needs: (Please describe) Please type or print clearly _____________________________________________________________ Last name ____________________________________________________________ First Name _____________________________________________________________ Company/Organization _____________________________________________________________ Address _____________________________________________________________ _____________________________________________________________ ______________________________________________________________ Country ______________________________________________________________ Telephone Number ______________________________________________________________ Fax number ______________________________________________________________ e-mail address ______________________________________________________________ Name desired for your name tag ACM Member No. _____________________________ Payment Information [] Check or money order payable to MobiCom'96 [] VISA [] MasterCard Card Number _______________________________________ Expiration Date ___________________________________ ___________________________________________________ Print name above as it appears on card Please complete and send form and a check, credit card info or money orders (no purchase orders) to the registration chair. Registration accepted via postal mail, fax, or e-mail only. Fax and Email registration require credit card info. The registration fees must be paid in U.S. dollars. Send Payment To: MobiCom'96 Attn: Pravin Bhagwat IBM, TJ Watson Research Center US Mail PO Box 704 Yorktown Heights, NY 10598 Street Address 30 Saw Mill River Road for express Mail Hawthorne, N.Y. 10532 E-mail pravin@watson.ibm.com Fax 914-784-6205 Note: Written requests for refunds must be postmarked no later than November 1, 1996. Refunds are subject to a US$50 service charge. Participants with confirmed registration who fail to attend or notify MobiCom registration of cancelation before the refund date are subject to the full fee. Substitutions are allowed at any time. Registrations received after November 1, 1996 will be processed on-site. Mobicom'96 Executive committee GENERAL CO-CHAIRS: HAMID AHMADI RANDY KATZ IBM T. J. Watson Research Center,NY UC Berkeley, CA PROGRAM CO-CHAIRS IAN F. AKYILDIZ ZYGMUNT J. HAAS Georgia Tech, GA Cornell University TUTORIAL CHAIR LOCAL CHAIR ARVIND KRISHNA BOB FLYNN, Polytechnic University IBM T.J. Watson Research Center VICE CHAIR TOM LaPORTA, Bell Labs. (Lucent Tech.) TREASURER PUBLICITY CHAIR RAVI JAIN, Bellcore B.R. BADRINATH, Rutgers Univ. REGISTRATION CHAIR Pravin Bhagwat IBM, TJ Watson Research Center STEERING COMMITTEE CHAIR IMRICH CHLAMTAC, Boston Univ. PROGRAM COMMITTEE Rafael Alonso, Matsushita Labs Victor Bahl, DEC Brian Bershad, U. of Washington Ramon Caceres, Bell Labs (Lucent Tech.) Imrich Chlamtac, Boston U. Tony Dahbura, Motorola John Daigle, U. of Mississippi Maurizio Decina, CEFRIEL JJ Garcia Luna, UC Santa Cruz Mario Gerla, UCLA Peter Honeyman, U. of Michigan Pierre Humblet, Eurecom Tom Imielinski, Rutgers U. David Johnson, CMU Phil Karn, Qualcomm Mark Karol, Bell labs (Lucent Tech.) Jay Kistler, DEC Barry Leiner, ARPA Jason Ying Bin Lin, NCTU Teresa Meng, Stanford U. Mahmoud Naghshineh, IBM TJ Peter O'Reilly, GTE Labs Charlie Perkins, IBM TJ Ray Pickholtz, GWU Dhiraj Pradhan, Texas A&M Chris Rose, Rutgers U. Krishan Sabnani, Bell Labs(Lucent Tech.) Mischa Schwartz, Columbia U. Martha Steenstrup, BBN Gordon Stuber, GaTech David Tennenhouse, MIT Marvin Theimer, XEROX Mehmet Ulema, Bellcore Newman Wilson, D. Sarnoff RC Parviz Yegani, Qualcomm From rem-conf-request@es.net Fri Aug 16 17:29:35 1996 Received: from cs.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 16 Aug 1996 14:29:01 -0700 Received: from tune.cs.columbia.edu (tune.cs.columbia.edu [128.59.10.5]) by cs.columbia.edu (8.7.5/8.6.6) with ESMTP id RAA20868; Fri, 16 Aug 1996 17:28:55 -0400 (EDT) Received: from tune.cs.columbia.edu (localhost [127.0.0.1]) by tune.cs.columbia.edu (8.7.5/8.6.6) with SMTP id RAA06395; Fri, 16 Aug 1996 17:28:51 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <3214E813.506B@cs.columbia.edu> Date: Fri, 16 Aug 1996 17:28:51 -0400 From: "Henning G. Schulzrinne" Organization: Columbia University X-Mailer: Mozilla 3.0b7 (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: ietf@ietf.org, rem-conf@es.net Subject: CFP: IEEE Communications Magazine, Internet Technology Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Call For Papers Venue: IEEE Communications Magazine What: New Feature Series on Internet Technology Deadline: Sept. 1, 1996 for January 1997 publication (feature series to appear every six months) Details: http://www.cs.columbia.edu/~hgs/ComMag/ -- Henning Schulzrinne email: schulzrinne@cs.columbia.edu (NEW!) Dept. of Computer Science phone: +1 212 939-7042 Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs From rem-conf-request@es.net Mon Aug 19 08:02:06 1996 Received: from cosmail1.ctd.ornl.gov by osi-west.es.net with ESnet SMTP (PP); Mon, 19 Aug 1996 05:01:11 -0700 Received: from [128.219.154.21] (pucpmac.ctd.ornl.gov [128.219.154.21]) by cosmail1.ctd.ornl.gov (8.7.4/8.7.3) with SMTP id IAA27249; Mon, 19 Aug 1996 08:01:04 -0400 (EDT) X-Sender: hny@cosmail1.ctd.ornl.gov Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 Aug 1996 08:01:05 -0400 To: "Henning G. Schulzrinne" , ietf@ietf.org, rem-conf@es.net From: hny@ornl.gov (Gary Haney) Subject: Re: CFP: IEEE Communications Magazine, Internet Technology At 5:28 PM 8/16/96, Henning G. Schulzrinne wrote: >Call For Papers > >Venue: IEEE Communications Magazine >What: New Feature Series on Internet Technology >Deadline: Sept. 1, 1996 for January 1997 publication (feature series > to appear every six months) >Details: http://www.cs.columbia.edu/~hgs/ComMag/ >-- Expect a submission from me and several other co-authors. >Henning Schulzrinne email: schulzrinne@cs.columbia.edu (NEW!) >Dept. of Computer Science phone: +1 212 939-7042 >Columbia University fax: +1 212 666-0140 >New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs #include ---------------------------------------------------------------------------- ------------ "Do as much as you can, for as many as you can, for as long as you can." - James Elcany Harr (1881-1972) ---------------------------------------------------------------------------- ------------ U.S. Mail: Gary Haney Lockheed Martin Oak Ridge National Laboratory 701 Scarboro Rd. MS8227, Rm 328 Oak Ridge, Tn 37831 Phone: 423.574.4629 (Voice) 423.576.0099(Fax) 423.873.4467 (Beeper) Email: hny@ornl.gov (Internet) URL: ---------------------------------------------------------------------------- ------------ From rem-conf-request@es.net Tue Aug 20 21:22:11 1996 Received: from ell.ee.lbl.gov by osi-west.es.net with ESnet SMTP (PP); Tue, 20 Aug 1996 18:21:39 -0700 Received: by ell.ee.lbl.gov (8.7.5/1.43r) id SAA06799; Tue, 20 Aug 1996 18:21:38 -0700 (PDT) From: mccanne@ee.lbl.gov (Steven McCanne) Message-Id: <199608210121.SAA06799@ell.ee.lbl.gov> To: rem-conf@es.net Subject: MBone broadcast of "Berkeley Lab 65th Anniversary Week" Date: Tue, 20 Aug 96 18:21:38 PDT We plan to broadcast the Berkeley Lab 65th Anniversary Week keynote lectures over the MBone. There will be a noon lecture each day next week by a leading Berkeley Lab scientist. More information on the series is available at: http://www.lbl.gov/Science-Articles/anniversary-schedule.html Audio format will be RTP/DVI and video will be H.261. The session is announced in sdr. Please let mccanne@ee.lbl.gov or kfall@ee.lbl.gov know if there are any problems or conflicts. Thanks, Steven McCanne From rem-conf-request@es.net Wed Aug 21 21:54:35 1996 Received: from bridge2.NSD.3Com.COM by osi-west.es.net with ESnet SMTP (PP); Wed, 21 Aug 1996 18:54:02 -0700 Received: from dutch.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA24708 (5.65c/IDA-1.4.4nsd for ); Wed, 21 Aug 1996 18:54:00 -0700 Received: from localhost by dutch.NSD.3Com.COM with SMTP id AA00420 (5.65c/IDA-1.4.4-910730); Wed, 21 Aug 1996 18:47:45 -0700 Date: Wed, 21 Aug 1996 18:47:45 -0700 (PDT) From: Nair Venugopal To: rem-conf@es.net Cc: venu@nsd.3com.com Subject: Problem with Sparc5 audio patch Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Apologies if this has already been discussed on the list. Since I couldnt get any audio with vat4b, I tried installing patch 102161-04 on my Sparc5 running SunOS 4.1.3U1. However, while building the new kernel, the compilation fails saying "../../sun/conf.c: 763: Can't find include file audiocs.h" Am I trying to install the wrong patch? Thanks. --Venu (email: venu@nsd.3com.com) From rem-conf-request@es.net Fri Aug 23 13:10:59 1996 Received: from mercury.Sun.COM by osi-west.es.net with ESnet SMTP (PP); Fri, 23 Aug 1996 10:10:28 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA22997; Fri, 23 Aug 1996 10:10:10 -0700 Received: from rebma. by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA17612; Fri, 23 Aug 1996 10:09:47 -0700 Received: by rebma. (5.x/SMI-SVR4) id AA28656; Fri, 23 Aug 1996 10:09:39 -0700 Date: Fri, 23 Aug 1996 10:09:39 -0700 From: hoffman@rebma.Eng.Sun.COM (Don Hoffman) Message-Id: <9608231709.AA28656@rebma.> To: rem-conf@es.net Subject: Changes to draft-ietf-avt-mpeg-01.txt X-Sun-Charset: US-ASCII At the last moment Vivek Goyal discovered an error in the MPEG RTP encapsulation document, draft-ietf-avt-mpeg-01.txt. This will result in a minor change as the document goes to RFC. Specifically, we incorrectly only allocated 2 bits for the "Picture-Type" field in the MPEG video-specific header (Section 3.4 in the draft). This was not enough to represent the full set of MPEG-compliant values. The change to the spec is to allocate 3 bits for this field. The full text of the modified draft can be found on: ftp://playground.sun.com/pub/hoffman/papers/draft-ietf-avt-mpeg-02.txt Specifically, we would like to know if this has an impact on any existing implementations, and/or if someone else has made some other choice to resolve the issue. Thanks, Don Hoffman Sun Microsystems, Inc. email - hoffman@eng.sun.com, phone - +1 503 297 1580, fax - +1 503 297 2880 From rem-conf-request@es.net Sat Aug 24 00:03:36 1996 Received: from littlewing.mcom.com (actually h-205-217-255-33.netscape.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 23 Aug 1996 21:03:08 -0700 Received: (from sclatter@localhost) by littlewing.mcom.com (8.7.3/8.7.3) id VAA16386; Fri, 23 Aug 1996 21:06:06 -0700 (PDT) Received: from maleman.mcom.com (maleman.mcom.com [198.93.92.3]) by tera.mcom.com (8.6.12/8.6.9) with ESMTP id MAA02850 for ; Fri, 23 Aug 1996 12:25:29 -0700 Received: from ns.netscape.com (ns.netscape.com.mcom.com [198.95.251.10]) by maleman.mcom.com (8.6.9/8.6.9) with ESMTP id MAA10531 for ; Fri, 23 Aug 1996 12:22:18 -0700 Received: from osi-west.es.net (osi-west.es.net [198.128.3.61]) by ns.netscape.com (8.7.3/8.7.3) with SMTP id MAA00772 for ; Fri, 23 Aug 1996 12:21:07 -0700 (PDT) Received: from mercury.Sun.COM by osi-west.es.net with ESnet SMTP (PP); Fri, 23 Aug 1996 10:10:28 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA22997; Fri, 23 Aug 1996 10:10:10 -0700 Received: from rebma. by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA17612; Fri, 23 Aug 1996 10:09:47 -0700 Received: by rebma. (5.x/SMI-SVR4) id AA28656; Fri, 23 Aug 1996 10:09:39 -0700 Date: Fri, 23 Aug 1996 10:09:39 -0700 From: hoffman@rebma.Eng.Sun.COM (Don Hoffman) Message-Id: <9608231709.AA28656@rebma.> To: rem-conf@es.net Subject: Changes to draft-ietf-avt-mpeg-01.txt X-Sun-Charset: US-ASCII At the last moment Vivek Goyal discovered an error in the MPEG RTP encapsulation document, draft-ietf-avt-mpeg-01.txt. This will result in a minor change as the document goes to RFC. Specifically, we incorrectly only allocated 2 bits for the "Picture-Type" field in the MPEG video-specific header (Section 3.4 in the draft). This was not enough to represent the full set of MPEG-compliant values. The change to the spec is to allocate 3 bits for this field. The full text of the modified draft can be found on: ftp://playground.sun.com/pub/hoffman/papers/draft-ietf-avt-mpeg-02.txt Specifically, we would like to know if this has an impact on any existing implementations, and/or if someone else has made some other choice to resolve the issue. Thanks, Don Hoffman Sun Microsystems, Inc. email - hoffman@eng.sun.com, phone - +1 503 297 1580, fax - +1 503 297 2880 --MAA02851.840828336/tera.mcom.com-- From rem-conf-request@es.net Sat Aug 24 00:23:25 1996 Received: from littlewing.mcom.com (actually h-205-217-255-33.netscape.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 23 Aug 1996 21:22:51 -0700 Received: (from sclatter@localhost) by littlewing.mcom.com (8.7.3/8.7.3) id VAA18400; Fri, 23 Aug 1996 21:25:51 -0700 (PDT) Received: from maleman.mcom.com (maleman.mcom.com [198.93.92.3]) by tera.mcom.com (8.6.12/8.6.9) with ESMTP id TAA10545 for ; Thu, 22 Aug 1996 19:03:59 -0700 Received: from ns.netscape.com (ns.netscape.com.mcom.com [198.95.251.10]) by maleman.mcom.com (8.6.9/8.6.9) with ESMTP id UAA27989 for ; Tue, 20 Aug 1996 20:26:25 -0700 Received: from osi-west.es.net (osi-west.es.net [198.128.3.61]) by ns.netscape.com (8.7.3/8.7.3) with SMTP id UAA27841 for ; Tue, 20 Aug 1996 20:25:26 -0700 (PDT) Received: from ell.ee.lbl.gov by osi-west.es.net with ESnet SMTP (PP); Tue, 20 Aug 1996 18:21:39 -0700 Received: by ell.ee.lbl.gov (8.7.5/1.43r) id SAA06799; Tue, 20 Aug 1996 18:21:38 -0700 (PDT) From: mccanne@ee.lbl.gov (Steven McCanne) Message-Id: <199608210121.SAA06799@ell.ee.lbl.gov> To: rem-conf@es.net Subject: MBone broadcast of "Berkeley Lab 65th Anniversary Week" Date: Tue, 20 Aug 96 18:21:38 PDT We plan to broadcast the Berkeley Lab 65th Anniversary Week keynote lectures over the MBone. There will be a noon lecture each day next week by a leading Berkeley Lab scientist. More information on the series is available at: http://www.lbl.gov/Science-Articles/anniversary-schedule.html Audio format will be RTP/DVI and video will be H.261. The session is announced in sdr. Please let mccanne@ee.lbl.gov or kfall@ee.lbl.gov know if there are any problems or conflicts. Thanks, Steven McCanne --TAA10548.840766062/tera.mcom.com-- From rem-conf-request@es.net Tue Aug 27 08:54:23 1996 Received: from goggins.uio.no by osi-west.es.net with ESnet SMTP (PP); Tue, 27 Aug 1996 05:53:47 -0700 Received: from ulrik.uio.no by goggins.uio.no with local-SMTP (PP) id <11743-0@goggins.uio.no>; Tue, 27 Aug 1996 14:53:29 +0200 Received: from marion (localhost [127.0.0.1]) by marion.uio.no ; Tue, 27 Aug 1996 12:53:15 GMT Message-Id: <199608271253.MAA10253@marion.uio.no> X-Mailer: exmh version 1.6.7 5/3/96 To: rem-conf@es.net Subject: Multicast & os2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Aug 1996 14:53:12 +0200 From: Frank J|rgen Solem IP multicasting is now supported in win32 and I'm wondering if OS/2 also supports it. If multicast is possible with OS/2, will win95 multicast programs work under OS/2 and are there any multicast programs especially for OS/2? If OS/2 not already supports multicast, are there any work on implementing it? --frank From rem-conf-request@es.net Tue Aug 27 14:40:36 1996 Received: from george.lbl.gov (actually george-2.lbl.gov) by osi-west.es.net with ESnet SMTP (PP); Tue, 27 Aug 1996 11:39:46 -0700 Received: (hoo@localhost) by george.lbl.gov (8.6.10/8.6.5) id LAA23821 for rem-conf@es.net; Tue, 27 Aug 1996 11:39:44 -0700 From: "Gary Hoo [SFSU student]" Message-Id: <199608271839.LAA23821@george.lbl.gov> Subject: Re: MBone broadcast of "Berkeley Lab 65th Anniversary Week" To: rem-conf@es.net Date: Tue, 27 Aug 1996 11:39:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1013 It appears that the original advertisement for this session in sdr has disappeared for some reason. Steve McCanne is unavailable to look into this matter, so we have taken the liberty of re-advertising the session. The audio format is still RTP/DVI and the video format is still H.261; however, the ports have changed. More information on the noontime lecture series being broadcast is available at: http://www.lbl.gov/Science-Articles/anniversary-schedule.html Please let gjhoo@lbl.gov know if there are any problems or conflicts. We apologize for any inconvenience that either the re-advertisement or this late notice causes. /gh --------------------------------------------------------------------- Gary Hoo DISCLAIMER: I do not speak for Lawrence Berkeley National Laboratory, the U.S. Government, or anyone else who gives me Internet access. --------------------------------------------------------------------- From rem-conf-request@es.net Tue Aug 27 14:53:06 1996 Received: from aruba.lerc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Tue, 27 Aug 1996 11:52:25 -0700 Received: from captiva.lerc.nasa.gov by aruba.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id OAA22503; Tue, 27 Aug 1996 14:52:23 -0400 (EDT) Received: from [139.88.27.112] by captiva.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id OAA28585; Tue, 27 Aug 1996 14:52:21 -0400 (EDT) X-Sender: yywhy@popserve.lerc.nasa.gov Message-Id: Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Date: Tue, 27 Aug 1996 14:52:18 -0400 To: rem-conf@es.net From: Michael Baldizzi Subject: Recent Advances in 100 Mbps Networking Technologies NASA Lewis Research Center plans to broadcast a seminar on "Recent Advances in 100 Mbps Networking Technologies" by Prof. Raj Jain The Ohio State University on Wednesday, August 28, 1996, 10:00-11:30 AM (EST) over the MBone. About the Topic Ethernet, which was originally standardized at 10 Mbps, has now been extended to run at 100 Mbps. While 100 Mbps "Ethernet" was being standardized, Hewlett-Packard came up with a competing proposal now called 100VG-AnyLAN, which allows delay-sensitive continuous media traffic such as video and voice to be transmitted along with delay-insensitive data traffic. Fiber Distributed Data Interface (FDDI), another popular option available at this speed, will also be discussed. The principles of operation of these LAN technologies will be explained in this seminar including how these are different from each other and what was done to increase the speed of Ethernet from 10 Mbps to 100 Mbps. About the Speaker Raj Jain is a Professor of Computer and Information Science at the Ohio State University. He is the award winning author of "FDDI Handbook" and "The Art of Computer Systems Performance Analysis." Dr. Jain is the Past Vice-Chair of ACM SIGCOMM, an ACM Lecturer, an IEEE Distinguished Visitor, a Fellow of the IEEE and a Fellow of ACM. He is an active participant of ATM Forum Traffic Management working group. For further information see his web page at http://www.cis.ohio-state.edu/~jain/ Audio format will be RTP/PCM, video will be H.261 and includes a wb presentation. The session is announced in sdr. Please let mbaldizzi@lerc.nasa.gov or bfrantz@lerc.nasa.gov know if there are any problems or conflicts. Thank you, Michael Baldizzi --------------------------------------------------------------- Michael Baldizzi MS142-1 Phone 216-433-5120 NASA Lewis Research Center Fax 216-433-8000 21000 Brookpark Road email mbaldizzi@lerc.nasa.gov Cleveland, OH 44135 From rem-conf-request@es.net Tue Aug 27 15:06:02 1996 Received: from central.bldrdoc.gov by osi-west.es.net with ESnet SMTP (PP); Tue, 27 Aug 1996 12:05:19 -0700 Received: from pinon.bldrdoc.gov (pinon [132.163.10.7]) by central.bldrdoc.gov (8.6.13/8.6.11) with ESMTP id NAA16226 for ; Tue, 27 Aug 1996 13:08:01 -0600 From: Paul R Franchois 303-497-5674 Received: (from paulf@localhost) by pinon.bldrdoc.gov (8.6.13/8.6.11) id NAA23919 for rem-conf@es.net; Tue, 27 Aug 1996 13:05:16 -0600 Date: Tue, 27 Aug 1996 13:05:16 -0600 Message-Id: <199608271905.NAA23919@pinon.bldrdoc.gov> To: rem-conf@es.net Subject: Win95 sdr snafu X-Sun-Charset: US-ASCII Folks, The sdr for Win95, version 2.2a12, has worked fine for several months, but just today, when invoking sdr, I get an sdr.exe error: socketfd too large (70 or 71), and get no furthur. I did lose my Mbone tunnel today while MCI's mbone machine is down. Is this a direct result of that? The PC is running the Onnet 2.1 stack on an Etherlink III NIC. Any ideas? Paul Franchois NIST/U.S. Dept. of Commerce Boulder, CO paulf@boulder.nist.gov From rem-conf-request@es.net Tue Aug 27 19:16:40 1996 Received: from europe.std.com by osi-west.es.net with ESnet SMTP (PP); Tue, 27 Aug 1996 16:16:09 -0700 Received: from world.std.com by europe.std.com (8.7.5/BZS-8-1.0) id TAA26141; Tue, 27 Aug 1996 19:16:06 -0400 (EDT) Received: by world.std.com (5.65c/Spike-2.0) id AA26367; Tue, 27 Aug 1996 19:14:03 -0400 Message-Id: <199608272314.AA26367@world.std.com> To: rem-conf@es.net Priority: Normal X-Mailer: Post Road Mailer (Green Edition Ver 2.0) Date: Tue, 27 Aug 1996 19:14:05 EST From: Chuck Grandgent Reply-To: Chuck Grandgent Subject: Re: Multicast & os2 ** Reply to note from Frank J|rgen Solem Tue, 27 Aug 1996 14:53:12 +0200 > > > IP multicasting is now supported in win32 and I'm wondering if OS/2 also > supports it. If multicast is possible with OS/2, will win95 multicast > programs work under OS/2 and are there any multicast programs especially > for OS/2? If OS/2 not already supports multicast, are there any work on > implementing it? > > --frank > > Path: news.zipnet.net!uunet!in3.uu.net!ott.istar!istar.net!tor.istar!east.istar!news From: craig@alpha.cyberplex.com (Craig Rodrigues) Newsgroups: comp.os.os2.beta Subject: Re: Does Merlin TCP/IP have Multicast support??? Date: 16 Aug 1996 04:31:38 GMT Organization: CyberPlex Interactive Media Lines: 19 Message-ID: <4v0tja$gft@nr1.toronto.istar.net> References: <32135904.130B@ibm.net> NNTP-Posting-Host: 207.81.40.2 In article <32135904.130B@ibm.net>, Milton Taylor wrote: >Hi all, > >Does anybody know for sure whether the TCP/IP >that is in Merlin contains support for IP >Multicast? Yes it does! It is not very well documented or hyped, but it does. Check out my home page at http://shakti.cyberplex.com/personal/projects/multicast.html which has one code example of multicast working under Merlin/TCPIP4.0. -- Craig Rodrigues CyberPlex Interactive Media Application Programmer 24 Duncan St., Suite 300 Toronto ON M5V 2B8 CANADA craig@cyberplex.com (416) 597-8889(voice) (416)597-2345(fax) > > > > ------------------------------------------------------------------------------- Chuck Grandgent, MultiLink Inc., Andover, Massachusetts k1om@world.std.com CIS:72330,450 (+1)508-691-2100 fax:(+1)508-691-2192 http://world.std.com/~k1om ------------------------------------------------------------------------------- From rem-conf-request@es.net Wed Aug 28 14:41:05 1996 Received: from dxmint.cern.ch by osi-west.es.net with ESnet SMTP (PP); Wed, 28 Aug 1996 08:46:03 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id RAA10904; Wed, 28 Aug 1996 17:45:29 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA15480; Wed, 28 Aug 1996 17:45:27 +0200 Message-Id: <9608281545.AA15480@dxcoms.cern.ch> Subject: MBONE Announcement for ATLAS Plenary meetings To: net-teleconferencing@listbox.cern.ch, htc@frcpn11.in2p3.fr, hrc@frcpn11.in2p3.fr, htasc@listbox.cern.ch, rem-conf@es.net, hepnet-l@slacvm.slac.stanford.edu Date: Wed, 28 Aug 1996 17:45:27 +0200 (MET DST) From: Martin Fluckiger - CERN/CN/CS 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 next Plenary Meetings of the ATLAS LHC Experiment Provisional Agenda: ------------------- Thursday 19th Sept: 09:00-13:00 (GMT+2): Physics Working Group 14:00-17:30 (GMT+2): Plenary Meeting (Part I) Friday 20th Sept: 08:30-13:00 (GMT+2): Plenary Meeting (Part II) The broadcast is announced via sdr. vat and vic will be used in RTPv2 mode with a ttl of 127. In case of questions or conflicts 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 Wed Aug 28 15:07:08 1996 Received: from VNET.IBM.COM by osi-east.es.net with ESnet SMTP (PP); Wed, 28 Aug 1996 12:06:32 -0700 Received: from HAIFASC3 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1110; Wed, 28 Aug 96 15:06:10 EDT Date: Wed, 28 Aug 96 22:05:48 IST From: Scott Petrack To: rem-conf@osi-east.es.net Subject: Problems with several RTP packets in one UDP write I am worried that there are some problems with using RTP in low bandwidth situations that I didn't really focus on until now. These may be well known, in which case I'd be grateful for the standard answers. I'm also worried that the utility of RTP compression as its now being formulated might be affected. (Thanks to Stas Khirman for bringing this to my attention). The problems occur when I wish to put several RTP packets into a single UDP datagram. I would do this to save protocol overhead. 1. First problem: the fact that there is no length field in RTP makes it difficult for an RTP processing layer to handle mutliple packets within a single datagram. If the coder is a standard one, with a payload format already defined, is there some standard way to deal with this problem? The length I get from UDP is the length of the whole UDP datagram, and I may have no way to know where the packets are. Is there some standard extension for the length of the packet? Has anyone else worried about this problem? 2. Second problem: putting several RTP packets into a single UDP datagram will seriously harm the effectiveness of the RTP/UDP/IP compression that's being formulated now. Now I can hear some clever person saying, "well, when you have RTP/UDP/IP compression, you won't *need* to put several RTP packets into a single datagram, because the compression will turn the overhead into 1-2 bytes per packet on the low bandwidth link." Well, people are trying to implement this stuff *now*, and it really will be a few weeks at least before C/RTP is deployed universally ;-). Is there a possible transition strategy for this? Now one solution is just to warn people that writing several RTP packets in one datagram will harm bandwith a lot once compression is enabled, so that they shouldn't do it. Or at least should provide some way to turn it off in the future. But if there is a sense that this is a thing which really will happen once RTP applications get deployed on 28.8 links, and that these applications will appear before C/RTP is widespread, then maybe we can agree on some specially effecient way to encode the length of the packet, perhaps with all the overhead of an extension. And then the compression algorithm should be aware of this, so that it can still help in this situation. Scott From rem-conf-request@es.net Wed Aug 28 18:41:43 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Wed, 28 Aug 1996 15:41:04 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 28 Aug 1996 23:40:11 +0100 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: Paul R Franchois 303-497-5674 cc: rem-conf@es.net Subject: Re: Win95 sdr snafu In-reply-to: Your message of "Tue, 27 Aug 96 13:05:16 MDT." <199608271905.NAA23919@pinon.bldrdoc.gov> Date: Wed, 28 Aug 96 23:40:07 +0100 Message-ID: <12912.841272007@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >The sdr for Win95, version 2.2a12, has worked fine for several >months, but just today, when invoking sdr, I get an sdr.exe >error: socketfd too large (70 or 71), and get no furthur. I >did lose my Mbone tunnel today while MCI's mbone machine is down. >Is this a direct result of that? John Brezak gave me a fix for a similar problem on Windows NT, which I guess will also fix this problem. There's a test version of sdr2.2a20 in ftp://cs.ucl.ac.uk/mice/sdrtest/ This works on Windows 95 and (I'm told) on NT 4.0, but not on NT 3.51. When I get back to London, I'll try and get an NT box setup to find the problem. Mark From rem-conf-request@es.net Wed Aug 28 20:07:43 1996 Received: from mailhub.Stanford.EDU by osi-east.es.net with ESnet SMTP (PP); Wed, 28 Aug 1996 17:07:15 -0700 Received: from solaria13.Stanford.EDU (solaria13.Stanford.EDU [36.216.0.13]) by mailhub.Stanford.EDU (8.7.5/8.7.3) with SMTP id RAA06035; Wed, 28 Aug 1996 17:07:07 -0700 (PDT) Sender: bbn01@leland.Stanford.EDU Message-ID: <3224DF27.3543@cs.columbia.edu> Date: Wed, 28 Aug 1996 17:07:03 -0700 From: bbn01 account X-Mailer: Mozilla 3.0 (X11; U; SunOS 5.5 sun4m) MIME-Version: 1.0 To: Scott Petrack CC: rem-conf@osi-east.es.net Subject: Re: Problems with several RTP packets in one UDP write References: <199608281944.PAA16754@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit (Regarding packing several RTP packets into a single UDP packet, as noted by Scott Petrack) Having a length "shim" was considered for ST-II encapsulation (for different reasons than the one you raise). Look at earlier drafts for details, if you care. However, it is not clear why you would want to do this. If you want to carry more (say) audio in a single UDP packet, there is no reason to create several RTP packets. For a long time, vat and NeVoT have allowed to put more than one encoding block into an RTP packet. For example, vat has always carried (I believe) 4 LPC blocks in one packet. (With NeVoT, you can collect as many as you like - and as you are willing to tolerate to loose at once + wait for). This requires no RTP extensions nor different payload types; different senders can even aggregate different numbers of encoding blocks. For audio, encodings are either block-oriented (known, fixed length) or sample-oriented. In either case, you know how much audio data is in the packet. I suppose block-based audio encodings with variable-length blocks are feasible and would require some kind of length byte. The VDVI encoding is variable length, but sample-oriented, so it does not cause difficulties. Henning From rem-conf-request@es.net Wed Aug 28 21:44:30 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Wed, 28 Aug 1996 18:43:47 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA08319; Wed, 28 Aug 1996 18:43:37 -0700 Date: Wed, 28 Aug 1996 18:43:36 -0700 (PDT) From: Stephen Casner To: Scott Petrack Cc: rem-conf@osi-east.es.net Subject: Re: Problems with several RTP packets in one UDP write In-Reply-To: <9608282002.AA07306@precept.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Scott, > The problems occur when I wish to put several RTP packets into a single > UDP datagram. I would do this to save protocol overhead. > 1. First problem: the fact that there is no length field in RTP makes it > difficult for an RTP processing layer to handle mutliple packets within > a single datagram. Section 10 of the RTP spec addresses this issue. If you want to put multiple RTP packets into one UDP packet, then you'll need to define some encapsulation of the RTP packets to go in between the two layers. The existing Profile does not define such an encapsulation, so using one is likely to impair interoperation. If you are talking about RTP packets from different streams being sent in one UDP packet, then you need some multiplexing information in the encapsulation as well as length information. > If the coder is a standard one, with a payload format > already defined, is there some standard way to deal with this problem? As Henning said, if you are talking about multiple RTP packets from a single stream, then you can generally put as much data into one RTP packet as you want (subject to MTU constraints). I believe this is true for all the payload formats that have been defined so far. Well, maybe you can only have one JPEG frame per packet, but that shouldn't be a problem. -- Steve From rem-conf-request@es.net Thu Aug 29 03:33:01 1996 Received: from VNET.IBM.COM by osi-east.es.net with ESnet SMTP (PP); Thu, 29 Aug 1996 00:32:22 -0700 Received: from HAIFASC3 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 6228; Thu, 29 Aug 96 03:31:59 EDT Date: Thu, 29 Aug 96 10:30:40 IST From: Scott Petrack To: rem-conf@osi-east.es.net, SCHULZRINNE@CS.COLUMBIA.EDU, casner@precept.com Subject: Re: Problems with several RTP packets in one UDP write Henning and Steve: >I suppose block-based >audio encodings with variable-length blocks are feasible and would >require some kind of length byte. The first case I had in mind was a video encoding which is block based with variable length blocks. There are indeed such coders. With audio, the problem would occur if I want to aggregate several blocks which happen to have some silence in between. I need a timestamp for the second audio burst to place it correctly. You might think that in such a case you really should send two datagrams, but there are cases where I'd really prefer to aggregate packets to save bandwidth. > Section 10 of the RTP spec addresses this issue. If you want to put > multiple RTP packets into one UDP packet, then you'll need to define > some encapsulation of the RTP packets to go in between the two > layers. The existing Profile does not define such an encapsulation, > so using one is likely to impair interoperation. Yes, so my question should have been phrased: does anyone else think that such an encapsulation should be defined and agreed upon, for use in these low bandwidth situations. > If you are talking about RTP packets from different streams being sent > in one UDP packet, then you need some multiplexing information in the > encapsulation as well as length information. I don't quite understand this comment. I am simply talking about about putting several RTP packets into one UDP packet, period. I think that all I need is an encapsulation with a length field to be able to get at the individual RTP packets if I do this. I don't think that I need anything more. Even if I multiplex different kinds of RTP packets in a way which is frowned upon by orthodox practitioners of RTP, I still only need the length to be able to get at the RTP packets within the datagram. Perhaps I didn't understand what you meant by "different streams" here. ("stream" is not defined in the RTP glossary, although I normally think that a stream is simply all the RTP packets in one session that have a particular SSRC). I just thought that when you start worrying about low bandwidth, it will indeed be useful to do this. I was hoping to get agreement on a standard way to do it, and also to ask that RTP compression take this as-yet-undefined standard way into account. Because of silence supression, this will be useful even in audio, and it will certainly be useful in video. Scott From rem-conf-request@es.net Thu Aug 29 10:41:44 1996 Received: from mailhub.Stanford.EDU by osi-east.es.net with ESnet SMTP (PP); Thu, 29 Aug 1996 07:41:09 -0700 Received: from solaria10.Stanford.EDU (solaria10.Stanford.EDU [36.216.0.10]) by mailhub.Stanford.EDU (8.7.5/8.7.3) with SMTP id HAA12357; Thu, 29 Aug 1996 07:41:01 -0700 (PDT) Sender: bbn01@leland.Stanford.EDU Message-ID: <3225AB8E.68C0@cs.columbia.edu> Date: Thu, 29 Aug 1996 07:41:07 -0700 From: bbn01 account X-Mailer: Mozilla 3.0 (X11; U; SunOS 5.5 sun4m) MIME-Version: 1.0 To: Scott Petrack CC: rem-conf@osi-east.es.net Subject: Re: Problems with several RTP packets in one UDP write References: <199608290800.EAA11430@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit For video, in particular JPEG, packet sizes are big enough that the header overhead is comparatively small, so the savings would be minuscule. Bridging silence in a single RTP packet is also likely to have almost no impact on overall bandwidth; certainly, your peak bandwidth is completely unaffected. (Obviously, you'd have to limit how big a silence period you would want to wait for in any event.) With the typical talkspurt durations, you'd save (at the most) one packet overhead every few seconds. Hardly worth the hassle and probably wiped out by the additional encapsulation overhead in every packet. Note that for doing this encapsulation, you would need some way of indicating that the UDP packet is containing several length-prefixed packets. If you do this implicitly, all the RTP (monitoring/recording/...) tools will break or require manual configuration. Henning From rem-conf-request@es.net Thu Aug 29 12:56:51 1996 Received: from burdell.cc.gatech.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 29 Aug 1996 09:56:20 -0700 Received: from fauna.cc.gatech.edu (kevin@fauna.cc.gatech.edu [130.207.8.21]) by burdell.cc.gatech.edu (8.7.5/8.6.9) with ESMTP id MAA06093 for ; Thu, 29 Aug 1996 12:56:19 -0400 (EDT) Received: (from kevin@localhost) by fauna.cc.gatech.edu (8.7.5/8.6.9) id MAA17291 for rem-conf@es.net; Thu, 29 Aug 1996 12:55:09 -0400 (EDT) Date: Thu, 29 Aug 1996 12:55:09 -0400 (EDT) From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199608291655.MAA17291@fauna.cc.gatech.edu> To: rem-conf@es.net Subject: MBone PC problems... In an effort to see the MBone tools running on a PC, I've been playing around with the PC versions of sdr, vic, and vat. After solving the path problems, et al. the latest problem is that the tcl for vic and vat die while trying to get a User Name. Is there a workaround for this? It seems the way I'm running Windows and vic and vat are having a hard time interacting, i.e. no user name, no home directory, etc. -Kevin Almeroth From rem-conf-request@es.net Thu Aug 29 15:01:05 1996 Received: from bmrc.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Thu, 29 Aug 1996 12:00:21 -0700 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 LAA29315 for <298-list@bmrc.Berkeley.EDU>; Thu, 29 Aug 1996 11:56:19 -0700 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 LAA28611 for <298-list@bmrc>; Thu, 29 Aug 1996 11:56:17 -0700 Date: Thu, 29 Aug 1996 11:56:17 -0700 Message-Id: <199608291856.LAA28611@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: U.C. Berkeley Multimedia & Graphics Seminar "The Case for Wireless Overlay Networks" Randy H. Katz University of California at Berkeley With the rapid growth in cellular telephony, it seems natural to expect a comparable growth in wireless data services. Unfortunately, there exists no integrated architecture that seamlessly integrates wireless services spanning satellites, wireless cable modems, cellular data overlays, packet radio networks, and wireless local area networks. Each is its own independent island of network connectivity. In this talk, we will provide an overview of the Daedalus Project, which is developing technology for the seamless integration of heterogeneous wireless subnetworks, in particular, mobile routing, transport, and application adaptation of multimedia data types across wide ranges in bandwidth and latency. This technology is being deployed in the Bay Area Research Wireless Access Network (BARWAN), being constructed with technology from IBM, AT&T/NCR, Metricom, Hybrid, and Hughes. The testbed includes in-building and wide-area wireless technologies, including satellite direct broadcast and wireless cable modems. The work is joint with Professor Eric Brewer. --- This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40 PST (GMT - 8 hrs). Instructions for setting up and running the MBONE tools are available at: http://www.bmrc.berkeley.edu/298/MBONE.html. Information about the broadcast is also available at the MBONE Broadcast Schedule Guide: http://www.msri.org/computing/mbone/ Information on future speakers at the seminar is available at: http://www.bmrc.berkeley.edu/298 This page is available on-line at: http://www.bmrc.berkeley.edu/298/w2.html From rem-conf-request@es.net Thu Aug 29 17:05:40 1996 Received: from bmrc.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Thu, 29 Aug 1996 14:05:02 -0700 Received: from euler.Berkeley.EDU (euler.Berkeley.EDU [128.32.142.1]) by bmrc.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id NAA29774 for <298-list@bmrc.Berkeley.EDU>; Thu, 29 Aug 1996 13:59:58 -0700 Received: by euler.Berkeley.EDU (8.6.10/1.28) id NAA24349; Thu, 29 Aug 1996 13:59:58 -0700 Date: Thu, 29 Aug 1996 13:59:58 -0700 From: aagogino@euler.Berkeley.EDU (Alice Agogino) Message-Id: <199608292059.NAA24349@euler.Berkeley.EDU> To: 298-list@bmrc.Berkeley.EDU, jerrlyn@postgres.berkeley.edu Subject: Re: U.C. Berkeley Multimedia & Graphics Seminar when will this be? alie >From jerrlyn@nobozo.CS.Berkeley.EDU Thu Aug 29 11:56:45 1996 Date: Thu, 29 Aug 1996 11:56:17 -0700 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: U.C. Berkeley Multimedia & Graphics Seminar "The Case for Wireless Overlay Networks" Randy H. Katz University of California at Berkeley With the rapid growth in cellular telephony, it seems natural to expect a comparable growth in wireless data services. Unfortunately, there exists no integrated architecture that seamlessly integrates wireless services spanning satellites, wireless cable modems, cellular data overlays, packet radio networks, and wireless local area networks. Each is its own independent island of network connectivity. In this talk, we will provide an overview of the Daedalus Project, which is developing technology for the seamless integration of heterogeneous wireless subnetworks, in particular, mobile routing, transport, and application adaptation of multimedia data types across wide ranges in bandwidth and latency. This technology is being deployed in the Bay Area Research Wireless Access Network (BARWAN), being constructed with technology from IBM, AT&T/NCR, Metricom, Hybrid, and Hughes. The testbed includes in-building and wide-area wireless technologies, including satellite direct broadcast and wireless cable modems. The work is joint with Professor Eric Brewer. --- This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40 PST (GMT - 8 hrs). Instructions for setting up and running the MBONE tools are available at: http://www.bmrc.berkeley.edu/298/MBONE.html. Information about the broadcast is also available at the MBONE Broadcast Schedule Guide: http://www.msri.org/computing/mbone/ Information on future speakers at the seminar is available at: http://www.bmrc.berkeley.edu/298 This page is available on-line at: http://www.bmrc.berkeley.edu/298/w2.html From rem-conf-request@es.net Thu Aug 29 17:17:17 1996 Received: from bmrc.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Thu, 29 Aug 1996 14:16:32 -0700 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 OAA29830 for <298-list@bmrc.Berkeley.EDU>; Thu, 29 Aug 1996 14:12:50 -0700 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 OAA05609 for <298-list@bmrc>; Thu, 29 Aug 1996 14:12:49 -0700 Date: Thu, 29 Aug 1996 14:12:49 -0700 Message-Id: <199608292112.OAA05609@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: U.C. Berkeley Multimedia & Graphics Seminar U.C. BERKELEY MULTIMEDIA AND GRAPHICS SEMINAR Wednesday, September 4, 1996 12:30 - 2:00 PDT 405 Soda Hall "The Case for Wireless Overlay Networks" Randy H. Katz University of California at Berkeley With the rapid growth in cellular telephony, it seems natural to expect a comparable growth in wireless data services. Unfortunately, there exists no integrated architecture that seamlessly integrates wireless services spanning satellites, wireless cable modems, cellular data overlays, packet radio networks, and wireless local area networks. Each is its own independent island of network connectivity. In this talk, we will provide an overview of the Daedalus Project, which is developing technology for the seamless integration of heterogeneous wireless subnetworks, in particular, mobile routing, transport, and application adaptation of multimedia data types across wide ranges in bandwidth and latency. This technology is being deployed in the Bay Area Research Wireless Access Network (BARWAN), being constructed with technology from IBM, AT&T/NCR, Metricom, Hybrid, and Hughes. The testbed includes in-building and wide-area wireless technologies, including satellite direct broadcast and wireless cable modems. The work is joint with Professor Eric Brewer. --- This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40 PST (GMT - 8 hrs). Instructions for setting up and running the MBONE tools are available at: http://www.bmrc.berkeley.edu/298/MBONE.html. Information about the broadcast is also available at the MBONE Broadcast Schedule Guide: http://www.msri.org/computing/mbone/ Information on future speakers at the seminar is available at: http://www.bmrc.berkeley.edu/298 This page is available on-line at: http://www.bmrc.berkeley.edu/298/w2.html From rem-conf-request@es.net Fri Aug 30 11:33:30 1996 Received: from tis-mail.thepoint.net (actually tis-backup.thepoint.net) by osi-west.es.net with ESnet SMTP (PP); Fri, 30 Aug 1996 08:33:01 -0700 Received: by tis-mail.thepoint.net with Microsoft Exchange (IMC 4.0.837.3) id <01BB9666.E01DA390@tis-mail.thepoint.net>; Fri, 30 Aug 1996 11:32:07 -0400 Message-ID: From: Arlie Davis To: "'mbone@isi.edu'" , "'rem-conf@es.net'" , Michael Jung , 'Ross Finlayson' , 'Mark Handley' , 'Robert Mozenter' Subject: Release 2.0 alpha of my Win32 Session Directory Date: Fri, 30 Aug 1996 11:29:47 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I've gotten quite a lot of mail asking about the next version of my session directory tool for Win32. The next version, 2.0, is not ready for release yet, but I am releasing a current alpha. This implements many things that were not there before: the tool can now create and advertise sessions, can cache existing sessions, and lots more. Lots of bug fixes, etc. The new tool is available at these URLs: http://archive.thepoint.net/Win32SD/ ftp://archive.thepoint.net/Win32SD/ Give it a try, let me know what you think. -- arlie