From rem-conf-request@es.net Wed Sep 01 04:24:52 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <20726-0@osi-east.es.net>; Wed, 1 Sep 1993 01:24:18 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 1 Sep 1993 09:23:20 +0100 To: Don.Hoffman@Eng.Sun.COM (Don Hoffman) cc: rem-conf@es.net Subject: Re: Call for Participation - IMA Network Focus Group In-reply-to: Your message of "Tue, 31 Aug 93 13:27:35 PDT." <9308312027.AA19395@amber.Eng.Sun.COM> Date: Wed, 01 Sep 93 09:23:19 +0100 From: Jon Crowcroft > Call for Participation - IMA Network Focus Group >A new Focus Group (FoG) has recently been formed within the >Architecture Technical Working Group (ATWG) of IMA to deal with the >networking and protocol issues relating to the multimedia system >services (MSS) framework being defined by the ATWG. The goal of this >group is to specify the network service interfaces and protocols used >within the MSS sufficiently to allow inter-operation between compatible >end-systems. there are getting to be so many journals, workshops, conferences and working groups on multimedia and multiservice networks, that anyone trying to actually get work done is findign their time diluted by tracking any other work.... any chance of some rationing/rationalising ? how does the IMA effort add to exisiting IETF, RACE programs and ARPA, DoE, and NSF and other funded programs? how do its efforts relate to standardisation on QoS for instance in ITU (and in IETF/Isoc)? is it concentrating on ATM or IP or other based networks? is it going to head the way of the ATM forum in costs? what liason links does it have with the above and others? thanks jon From rem-conf-request@es.net Wed Sep 01 08:56:08 1993 Received: from mcenroe.cs.unc.edu by osi-east.es.net via ESnet SMTP service id <21687-0@osi-east.es.net>; Wed, 1 Sep 1993 05:55:31 +0000 Received: from jeffay by mcenroe.cs.unc.edu (5.65/UNC_08_21_92) id AA09206; Wed, 1 Sep 93 08:55:25 -0400 Received: from localhost by jeffay.cs.unc.edu (5.65/UNC_02-28-90) id AA10420; Wed, 1 Sep 93 08:55:21 -0400 Message-Id: <9309011255.AA10420@jeffay.cs.unc.edu> To: rem-conf@es.net Subject: CFP: WORKSHOP ON THE ROLE OF REAL-TIME IN MULTIMEDIA/INTERACTIVE COMPUTING SYSTEMS Date: Wed, 01 Sep 93 08:55:18 EDT From: jeffay@cs.unc.edu CALL FOR PAPERS WORKSHOP ON THE ROLE OF REAL-TIME IN MULTIMEDIA/INTERACTIVE COMPUTING SYSTEMS November 30, 1993, Raleigh-Durham, North Carolina Sponsored by the IEEE Computer Society TC on Real-Time Systems SCOPE: There will be a workshop on the "Role of Real-Time in Multimedia/Interactive Computing" in conjunction with the 14th IEEE Real-Time Systems Symposium. Opinions range from "there is no role for real-time, just buy a faster processor" to "multimedia/interactive are real-time systems not unlike Command, Control and Communication (C3) Systems". This workshop is an attempt to bring together researchers and practitioners from across this opinion spectrum to cleanly identify and delineate the role of real-time in commercial multimedia/interactive systems. The emergence of multimedia systems into the commercial mainstream is creating new opportunities and challenges for the real-time research community. The opportunity is for the real-time community to have broad commercial impact. The challenge is for the real-time community to clearly demonstrate its value added to the commercial community. Specifically, the theory and practice of real-time computing is not only necessary, but is also the cost effective engineering approach for commercial multimedia/interactive systems. SUBMISSIONS: We are seeking 5 page position papers which: - illustrate where real-time capabilites are/are not required, - articulate the relationship between classical real-time systems, multimedia/interactive commercial systems, and general purpose computing systems, - capture the research challenges associated with widespead commercially available multimedia/interactive systems, - characterize multimedia data types and control types, - propose multimedia/interactive computing benchmarks, - summarize industry specific computing requirements, - report on tools and programming support for evaluation and realization of multimedia/interactive applications. Please send 5 copies of your submission to Jay K. Strosnider, Department of Electrical and Computer Engineering, Carnegie Mellon University, Pittsburgh, PA 15213. DEMO/VIDEO SESSION: On the evening of the workshop there will demo/video session where interested parties are encouraged to bring demonstrations of their respective technologies and/or videos. This session will be open not only to workshop participants, but also to all RTSS attendees arriving that evening. Reservations for space and/or video equipment are required. SCHEDULE: Position papers and demo/video session proposals are due by September 15, 1993, Notification to authors will be by November 1, 1993. For more information, contact Jay K. Strosnider by email at strosnider@ece.cmu.edu STEERING COMMITTEE: Jay Strosnider (CMU), Kevin Jeffay (UNC), Karsten Schwan (Georgia Tech), Roger Dannenberg (CMU), Duane Northcutt (Sun Microsystems), Dave Sincoskie (Bellcore), Wei Zhao (Texas A&M). From rem-conf-request@es.net Wed Sep 01 11:07:24 1993 Received: from sics.se by osi-east.es.net via ESnet SMTP service id <22351-0@osi-east.es.net>; Wed, 1 Sep 1993 08:06:48 +0000 Received: from bugs.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA24100; Wed, 1 Sep 93 17:06:41 +0200 Message-Id: <9309011506.AA24100@sics.se> To: " (Bob Braden)" Cc: rem-conf@es.net Subject: Re: query about nv_recrod In-Reply-To: Your message of "Fri, 20 Aug 1993 23:09:52 +0200." <199308202109.AA21423@zephyr.isi.edu> Date: Wed, 01 Sep 1993 17:06:40 +0200 From: Anders Klemets According to Toerless Eckert things will work fine if you remove the 'if' statement in nv_play.c that leads to the "wrong version" message. It's all magic to me however. I've just had a brief at my code and I can't see what the problem is. If someone could make sample recording that triggers this available to me, I might be able to figure out what is happening. Anders From rem-conf-request@es.net Wed Sep 01 14:19:56 1993 Received: from sics.se by osi-east.es.net via ESnet SMTP service id <24611-0@osi-east.es.net>; Wed, 1 Sep 1993 11:13:01 +0000 Received: from bugs.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA02643; Wed, 1 Sep 93 20:12:58 +0200 Message-Id: <9309011812.AA02643@sics.se> To: rem-conf@es.net Subject: New version of recording tools Date: Wed, 01 Sep 1993 20:12:57 +0200 From: Anders Klemets There is a new release of the suite of recording and playback tools for vat and nv. It fixes the bug that some of you have encountered when playing nv recordings. It also includes an enhancement by Mark Boolootian to the recording programs that allows one to specify the maximum number minutes to record (the -t flag), as well as the maximum number of bytes to record (the -b flag.) The source is available with anonymous ftp from sics.se. The filename is archive/vat_nv_record.tar.Z. The bug had to do with that I assumed that any packet received by nv_record would be smaller than 1500 bytes. One reason for this assumption is that the source routing multicast code is broken. When using source routing, a 1500 byte IP fragment would normally have to be split into two fragments at the tunnel entry point, since the source route adds a couple of extra bytes. Unfortunately, the source route will be incorrect in one of the two fragments. This fragment will be discarded by the tunnel endpoint. The original IP datagram can never be reassembled because of the missing fragment. Now that there is encapsulated tunneling, this problem has disappeared. It is still very inefficient, however, to send packets larger than the ethernet MTU since the fragments will still be split into two (one big fragment and one containing 20 bytes or so of data.) And with the addition of color to nv it seems like it is now possible to generate such big packets. However, I have tried to generate big packets with nv 3.2 but the most I get is 1100 bytes or so. But apparently it does happen sometimes. Anders From rem-conf-request@es.net Wed Sep 01 15:29:58 1993 Received: from alpha.Xerox.COM by osi-east.es.net via ESnet SMTP service id <26073-0@osi-east.es.net>; Wed, 1 Sep 1993 12:29:12 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <12169>; Wed, 1 Sep 1993 12:28:51 -0700 Received: by ecco.parc.xerox.com id <16136>; Wed, 1 Sep 1993 12:28:16 -0700 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.ecco.parc.xerox.com.sun4.41 via MS.5.6.ecco.parc.xerox.com.sun4_41; Wed, 1 Sep 1993 12:28:08 -0700 (PDT) Message-ID: Date: Wed, 1 Sep 1993 12:28:08 -0700 Sender: Ron Frederick From: Ron Frederick To: Anders Klemets Subject: Re: New version of recording tools CC: rem-conf@es.net In-Reply-To: <9309011812.AA02643@sics.se> References: <9309011812.AA02643@sics.se> > And with the addition of color to nv it seems like it is now possible > to generate such big packets. However, I have tried to generate big > packets with nv 3.2 but the most I get is 1100 bytes or so. But > apparently it does happen sometimes. In the normal case, nv will not generate packets which are larger than about 1k. It explicitly limits its data size to 1024 bytes. However, it goes a bit past that to fit in the end of the block currently in progress, and there was a problem in the way I was grouping a whole row of blocks which would sometimes make these chunks VERY large, causing packets to need fragmentation. This has been fixed in the next release... Thanks go to Steve McCanne for pointing out the cause of the problem. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Wed Sep 01 20:08:10 1993 Received: from Sun.COM by osi-east.es.net via ESnet SMTP service id <29214-0@osi-east.es.net>; Wed, 1 Sep 1993 16:59:58 +0000 Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA26553; Wed, 1 Sep 93 16:59:46 PDT Received: from amber.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA04689; Wed, 1 Sep 93 17:01:05 PDT Received: by amber.Eng.Sun.COM (5.0/SMI-SVR4) id AA01624; Wed, 1 Sep 93 16:59:32 PDT Date: Wed, 1 Sep 93 16:59:32 PDT From: Don.Hoffman@Eng.Sun.COM (Don Hoffman) Message-Id: <9309012359.AA01624@amber.Eng.Sun.COM> To: J.Crowcroft@cs.ucl.ac.uk Subject: Re: Call for Participation - IMA Network Focus Group Cc: rem-conf@es.net X-Sun-Charset: US-ASCII Content-Length: 3155 Jon, Good questions. I will try to anwer the ones specific to this working group. > >how does the IMA effort add to exisiting IETF, RACE programs and >ARPA, DoE, and NSF and other funded programs? IMA attempts to provide a forum to create and review specifications and proposal with a goal to facilitate interoperability among multimedia products. It has been around as a body for about 3 years. For further general information contact: Interactive Multimedia Association 3 Church Circle, Suite 800 Annapolis, MD 21401 USA phone: 410-626-1380 fax: 410-263 0590 The primary goal of the networking focus group is to clarify the network transport requirements from other IMA technical efforts (esp the Multimedia System Services (MSS) working group, which I can describe in another message if there is general interest), and to select, where possible, protocols from existing bodies of work to satify these requirements. We would expect that we would use work from the groups you mention (esp IETF) as likely sources for networking technology. Although I have a personal goal to make sure the Internet view is adequatly represented (by sending the notice to rem-conf for example), we will need to integrate the viewpoint of of the Consumer Video and VoD folks also (many of whom have never heard of IETF). I appreciate your comments on the proliferation of MM industry groups. It is an explict non-goal to create a new group for the definition of protocol standards. I do think there is a big hole in system-level standards. This is probably more where I see IMA value-added. There is a general unawareness on the part of many of the consumer and pc-desktop video folks that the Internet folks have anything to offer for video/audio. Participation by Internet folks in IMA would be one way to raise that awareneess. > >how do its efforts relate to standardisation on QoS for instance in >ITU (and in IETF/Isoc)? As I said above, likely to be a source for the technologies selected by this group. We need to have a discussion to determine how IMA should coordinate with IETF. I sent a direct copy to Casner to start the discussion as to how this group would work with AVT. There was some discussion at the DC IETF last year in the now inactive (?) remconf WG about a liason with IMA, but nothing seemed to have happened. I welcome specific suggestions. > >is it concentrating on ATM or IP or other based networks? A key goal, but not the primary goal (due to the breadth of interest of the IMA participants). > >is it going to head the way of the ATM forum in costs? Are you referring to membership costs? Not clear on the question. I don't think those making technical contributions to the WGs need to be members. > >what liason links does it have with the above and others? TBD for IETF. See above. IMA does have official liasons with a fair number of other groups. I wasn't going to dump a whole bunch of names on the net without asking them first (and I don't know them all off the top of my head), but if you have a specific one you are interested in, I can let you know. Thanks, Don > >thanks > > jon > > From rem-conf-request@es.net Thu Sep 02 11:55:42 1993 Received: from taurus.cs.nps.navy.mil by osi-east.es.net via ESnet SMTP service id <04705-0@osi-east.es.net>; Thu, 2 Sep 1993 08:46:35 +0000 Received: by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA00307; Thu, 2 Sep 93 08:47:22 PDT Date: Thu, 2 Sep 93 08:47:22 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9309021547.AA00307@taurus.cs.nps.navy.mil> To: rem-conf@es.net Subject: rem-conf: proposed mbone event There is a 2 1/2 day workshop that we would like to broadcast over MBONE Wednesday-Friday, 15-17 September 1993. The following preliminary program is being distributed for comments to the rem-conf@es.net list. We originally expected to only broadcast this regionally but if there is sufficient interest and minimal net conflict we are willing to raise the scope so that it is widely available over Internet/MBONE. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> << >> Please let me know if there is a schedule / bandwidth conflict, or << >> if you are interested in receiving the workshop at a remote distance. << >> << >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< We expect to put out single channel audio, single video at ~ 125 KBps and possibly a whiteboard on occasion. The source mrouter tunnel at ISDMNL.WR.USGS.GOV is not yet configured but it should originate adjacent to shopvac.stanford.edu. I am new to rem-conf so if this should also be posted to the mbone list please let me know. Thanks in advance. Donald P. Brutzman LCDR USN work (408) 656-2149 Code OR/Br Naval Postgraduate School [Glasgow 204] fax (408) 656-2595 Monterey California 93943-5000 USA home (408) 372-0190 ********************************************************************** Date: Thu, 2 Sep 1993 6:21:21 -0700 (PDT) From: "CAROL LAWSON, (415) 329-4030" Subject: Scientific Visualization Workshop program description This is a preliminary version of the program for the Scientific Visualization Workshop to be held at U.S. Geological Survey, Menlo Park CA on Wednesday-Friday, 15-17 September 1993. Of these descriptions, only twelve or so will be presented and broadcast in "talks". The remainder will be addressed in poster sessions and demonstrations in the poster area (the adjacent conference room to where we will hook up the MBONE). Because of schedule conflicts and changes in commitments, the program will vary somewhat each day. The format on Friday is a "public outreach" program. It will be a mini version of Wed and Thurs, but offered for over 125 invited guests (including the press). For any folks that would like to attend the workshop in person, I've prepared maps depicting the location of the USGS and building where the workshop will be held. These can be distributed as needed. Carol Lawson Workshop Coordinator U.S. Geological Survey 345 Middlefield Road, MS870 Menlo Park, CA 94025 (415) 329-4030 clawson@isdmnl.wr.usgs.gov ********************************************************************** MENLO PARK SCIENTIFIC VISUALIZATION WORKSHOP PROGRAM The Menlo Park Scientific Visualization Workshop will showcase a wide range of computer technologies and techniques utilized by scientists to visualize graphically the results of their investigations and analyses of various geologic, hydrologic, and topographic phenomena. Participants will include USGS employees and collaborative researchers from the following locations and organizations: Geologic Division Western Regional Geology, Menlo Park, CA Office of Earthquakes, Volcanoes and Engineering, Menlo Branch of Alaskan Geology, Anchorage, AK Office of International Geology, Menlo Water Resources Division Nevada District Office, Carson City, NV Menlo Park Regional Center Oregon District Office, Portland, OR National Center, Reston, VA California District Office, Sacramento, CA National Mapping Division, Menlo Information Systems Division Flagstaff Service Center Menlo Park Service Center National Center, Reston, VA Jet Propulsion Laboratory, Pasadena, CA NASA Ames, Mountain View, CA Naval Postgraduate School, Monterey, CA University of California at Santa Cruz, Santa Cruz, CA NASA Ames Research Center, Mountain View, CA Environmental Protection Agency, San Francisco, CA These scientists will demonstrate and describe the visualization techniques they use or have developed and will address the following topics: A series of interactive computer graphics visualization programs showing the hydrodynamic properties of the San Francisco Bay waters. (Ralph Cheng and Jon Burau, USGS, Menlo Park, CA) Computational geometry and stereoscopic visualization techniques used with earthquake hypocenter data to create a computer generated visual model of the volcanic structure underlying the island of Hawaii. (William Acevedo and Fred Klein USGS, Menlo Park, CA) Examples of terrain visualization and sensor interactions in an underwater virtual world provided from ongoing research and testing of the Naval Post Graduate School's Autonomous Underwater Vehicle (AUV) (Don Brutzman, Naval Postgraduate School, Monterey, CA) Interact with earthquakes! Interactive use of Amiga computer 2-D and 3-D animations to view current seismicity in 18 regions in California, fly along the face of the Loma Prieta aftershock zone, fly over the trace of the Hayward fault, and test your knowledge of California's active faults. (Fred Klein and Steve Walter, UGSG, Menlo Park, CA) What's under El Capitan? Borehole geophysical instruments and televiewing tools allow rocks, fractures, mineral veins, and faults to be mapped and studied to depths of more than 1,000 feet beneath the surface in Yosemite National Park. (Jim Borchers, USGS, Sacramento, CA) Visualization of circulation and effluent transport in Massachusetts Bay. (Harry Jenter and Rich Signell, USGS, Reston, VA) A rendering technique developed at UCSC that uses a metaphorical abstraction of virtual cans of spray paint for rendering data sets in various ways. (Alex Pang, University of California, Santa Cruz) NASA Ames' Virtual Planetary Exploration project, a research testbed which gives explorers access to a variety of planetary environments. (Cindy Ferguson, Michael McGreevy, Lew Hitchner, and Bill Briggs, NASA Ames Research Center, Mountain View, CA) A poster session of multi-scale maps of the Pacific continental margin and Exclusive Economic Zone (EEZ). (Florence Wong, USGS, Menlo Park, CA) Monterey Bay National Marine Sanctuary bathymetric visualization poster session. (Clint Steele, Carolyn Degnan, Michael Hamer, USGS, Menlo Park, CA) A video study of ten years of volcanic eruptions in Alaska including a night view of the eruption of Veniaminof, and day views of Akutan, West Dahl, Augustine, Redoubt and Spur eruptions. (Joseph Dorava, Robert McGimsey, and Mike Doukas, USGS, Anchorage, AK) A demonstration of the scientific visualization applications in Flagstaff showing past, present, and future capabilities using multimedia, CD-ROM, and video techniques. (Dennis McMacken and Lynda Bellisime, USGS, Flagstaff, AZ) A demonstration of the Macintosh digital mapping system computerized mapping process used to generate color separates for thematic maps. (Alex Acosta, USGS, Flagstaff, AZ) Two dimensional animated models of the formation of various ore deposit types that occur around the world. (Dan Mosier, USGS, Menlo Park, CA) Three dimensional animations of the evolution of landforms. (Tau Rho Alpha, USGS, Menlo Park, CA) A discussion of digital orthophotoquads (DOQs) including production, procedures, history, technical overview, and potential applications of this process developed at the Western Mapping Center. (Alan Mikuni and Lyman Ladner, USGS, Menlo Park, CA) A demonstration of the new topographic map production and revision process using digital line graph data (DLGs) and digital orthophotoquads (DOQs) of the Black Earth, Wisconsin 7.5' quadrangle. (Robert Lugo and Liz Wegenka, USGS, Menlo Park, CA) Accomplishments and future goals of the Monterey Bay Modeling Group with particular emphasis on research and public use of scientific visualization data. (Gary Greene, USGS, Menlo Park, CA) The visualization of synoptic topography of the United States, Italy, Sweden, and the Mediterranean by digital shaded relief (Richard Pike, USGS, Menlo Park, CA) Computation of time-series of topographic shading from digital elevation data for modeling temperatures of streams. (Brian Reece, USGS, Carson City, NV) Demonstration of a preliminary multi-agency network for interactive display and query of real-time data. (Tim Liebermann, USGS, Carson City, NV) Earthquakes as they happen: Near-real time epicenter locations via nationwide radio pagers. Displays of plots and text for California, national, and worldwide data. (Barbara Bogaert, USGS; A.L. Jones- SUNY, Bruce Julian, Alex Bittenbinder, and Al Lindh, USGS, Menlo Park, CA) A GIS interface with a particle tracker for a ground-water flow model developed to identify the location of recharge areas, locate contaminant sources, map the down-gradient parts of the flow system, and map the age of ground water throughout the ground- water flow system. (Dan Snyder, James Wilkinson, Leonard Orzol, USGS, Portland, OR) A complex monte carlo simulation model generated debris-flow hazard map of the Honolulu District of Oahu, Hawaii; with a Quicktime animated explanation of the model behind the map. (Bob Mark and Steve Ellen, USGS, Menlo Park, CA) Videotaped documentaries showing the potentially devastating New Madrid seismic zone near Memphis, Tennessee where the most powerful series of earthquakes known occurred in the early 1800s, and the geology of the Pacific Northwest, with particular emphasis on Hells Canyon, Idaho. (Doug Prose, USGS, Menlo Park, CA) A demonstration of the capabilities of Surveyor, an interactive software package used to develop 2-D and 3-D animations. Surveyor can be used to explore extremely large terrain databases and produce animations from these databases, and has been used in collaborative projects undertaken between USGS and JPL. (Kevin Hussey, Dan Stanfill, JPL, Pasadena, CA) A description of the technical preparations and capabilities which allow participating members of the Monterey Bay Modeling Group to view the USGS Scientific Visualization Workshop using the Internet via the Multicast Backbone known as MBONE. (Don Brutzman, Naval Postgraduate School, Monterey, CA) Description of multiple phases of the cooperative international Circumpacific Map Project which is designed to show the relationship of energy and mineral resources to major geologic features of the Pacific Basin and the surrounding continental areas. (George Gryc and Fran Mills, USGS-Menlo Park) Three dimensional shaded relief bathymetric imagery of coastal Central California created by offsetting the red and blue color channels. (Robert Hall, EPA-San Francisco, CA, Jere Swanson and Norman Maher, USGS, Menlo Park, CA) The workshop will take place on September 15 and 16 and the public outreach activity will take place on September 17, 1993. It will be held at the USGS Western Region Headquarters facility in Menlo Park, CA in Conference Facilities A and B, Building 3. Workshop attendance is free. Registration will take place at the door beginning at 7:45am on September 15th. For additional information please contact: Carol Lawson Workshop Coordinator U.S. Geological Survey 345 Middlefield Road, MS870 Menlo Park, CA 94025 (415) 329-4030 clawson@isdmnl.wr.usgs.gov From rem-conf-request@es.net Thu Sep 02 12:10:34 1993 Received: from hooter.oit.iupui.edu by osi-east.es.net via ESnet SMTP service id <04950-0@osi-east.es.net>; Thu, 2 Sep 1993 09:02:17 +0000 Received: by hooter.oit.iupui.edu (4.1/9.5jsm-jah) id AA06371; Thu, 2 Sep 93 10:59:07 EST Date: Thu, 2 Sep 93 10:59:07 EST From: dfleig Message-Id: <9309021559.AA06371@hooter.oit.iupui.edu> To: mbone@isi.com, rem-conf@es.net Subject: 4.1.3c and multicast Hi all, Has anyone had any experience installing the multicast kernal on a Sun LX running 4.1.3c? thanks in advance david From rem-conf-request@es.net Thu Sep 02 12:54:49 1993 Received: from bizarre.rtpnc.epa.gov by osi-east.es.net via ESnet SMTP service id <05563-0@osi-east.es.net>; Thu, 2 Sep 1993 09:45:50 +0000 Received: from localhost by bizarre.rtpnc.epa.gov (8.6.beta.10/1.34) id MAA02362; Thu, 2 Sep 1993 12:45:44 -0400 Date: Thu, 2 Sep 1993 12:45:44 -0400 From: Frank Terhaar-Yonkers Message-Id: <199309021645.MAA02362@bizarre.rtpnc.epa.gov> To: SHACKELFORD.WALTER@epamail.epa.gov, rem-conf@es.net Subject: rem-conf: proposed mbone event >From daemon Thu Sep 2 16:29:57 1993 >From rem-conf-request@es.net Thu Sep 2 12:29:57 1993 Date: Thu, 2 Sep 93 08:47:22 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) There is a 2 1/2 day workshop that we would like to broadcast over MBONE Wednesday-Friday, 15-17 September 1993. The following preliminary program is being distributed for comments to the rem-conf@es.net list. We originally expected to only broadcast this regionally but if there is sufficient interest and minimal net conflict we are willing to raise the scope so that it is widely available over Internet/MBONE. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> << >> Please let me know if there is a schedule / bandwidth conflict, or << >> if you are interested in receiving the workshop at a remote distance. << >> << >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< We expect to put out single channel audio, single video at ~ 125 KBps and possibly a whiteboard on occasion. The source mrouter tunnel at ISDMNL.WR.USGS.GOV is not yet configured but it should originate adjacent to shopvac.stanford.edu. I am new to rem-conf so if this should also be posted to the mbone list please let me know. Thanks in advance. Donald P. Brutzman LCDR USN work (408) 656-2149 Code OR/Br Naval Postgraduate School [Glasgow 204] fax (408) 656-2595 Monterey California 93943-5000 USA home (408) 372-0190 ********************************************************************** Date: Thu, 2 Sep 1993 6:21:21 -0700 (PDT) From: "CAROL LAWSON, (415) 329-4030" Subject: Scientific Visualization Workshop program description This is a preliminary version of the program for the Scientific Visualization Workshop to be held at U.S. Geological Survey, Menlo Park CA on Wednesday-Friday, 15-17 September 1993. Of these descriptions, only twelve or so will be presented and broadcast in "talks". The remainder will be addressed in poster sessions and demonstrations in the poster area (the adjacent conference room to where we will hook up the MBONE). Because of schedule conflicts and changes in commitments, the program will vary somewhat each day. The format on Friday is a "public outreach" program. It will be a mini version of Wed and Thurs, but offered for over 125 invited guests (including the press). For any folks that would like to attend the workshop in person, I've prepared maps depicting the location of the USGS and building where the workshop will be held. These can be distributed as needed. Carol Lawson Workshop Coordinator U.S. Geological Survey 345 Middlefield Road, MS870 Menlo Park, CA 94025 (415) 329-4030 clawson@isdmnl.wr.usgs.gov ********************************************************************** MENLO PARK SCIENTIFIC VISUALIZATION WORKSHOP PROGRAM The Menlo Park Scientific Visualization Workshop will showcase a wide range of computer technologies and techniques utilized by scientists to visualize graphically the results of their investigations and analyses of various geologic, hydrologic, and topographic phenomena. Participants will include USGS employees and collaborative researchers from the following locations and organizations: Geologic Division Western Regional Geology, Menlo Park, CA Office of Earthquakes, Volcanoes and Engineering, Menlo Branch of Alaskan Geology, Anchorage, AK Office of International Geology, Menlo Water Resources Division Nevada District Office, Carson City, NV Menlo Park Regional Center Oregon District Office, Portland, OR National Center, Reston, VA California District Office, Sacramento, CA National Mapping Division, Menlo Information Systems Division Flagstaff Service Center Menlo Park Service Center National Center, Reston, VA Jet Propulsion Laboratory, Pasadena, CA NASA Ames, Mountain View, CA Naval Postgraduate School, Monterey, CA University of California at Santa Cruz, Santa Cruz, CA NASA Ames Research Center, Mountain View, CA Environmental Protection Agency, San Francisco, CA These scientists will demonstrate and describe the visualization techniques they use or have developed and will address the following topics: A series of interactive computer graphics visualization programs showing the hydrodynamic properties of the San Francisco Bay waters. (Ralph Cheng and Jon Burau, USGS, Menlo Park, CA) Computational geometry and stereoscopic visualization techniques used with earthquake hypocenter data to create a computer generated visual model of the volcanic structure underlying the island of Hawaii. (William Acevedo and Fred Klein USGS, Menlo Park, CA) Examples of terrain visualization and sensor interactions in an underwater virtual world provided from ongoing research and testing of the Naval Post Graduate School's Autonomous Underwater Vehicle (AUV) (Don Brutzman, Naval Postgraduate School, Monterey, CA) Interact with earthquakes! Interactive use of Amiga computer 2-D and 3-D animations to view current seismicity in 18 regions in California, fly along the face of the Loma Prieta aftershock zone, fly over the trace of the Hayward fault, and test your knowledge of California's active faults. (Fred Klein and Steve Walter, UGSG, Menlo Park, CA) What's under El Capitan? Borehole geophysical instruments and televiewing tools allow rocks, fractures, mineral veins, and faults to be mapped and studied to depths of more than 1,000 feet beneath the surface in Yosemite National Park. (Jim Borchers, USGS, Sacramento, CA) Visualization of circulation and effluent transport in Massachusetts Bay. (Harry Jenter and Rich Signell, USGS, Reston, VA) A rendering technique developed at UCSC that uses a metaphorical abstraction of virtual cans of spray paint for rendering data sets in various ways. (Alex Pang, University of California, Santa Cruz) NASA Ames' Virtual Planetary Exploration project, a research testbed which gives explorers access to a variety of planetary environments. (Cindy Ferguson, Michael McGreevy, Lew Hitchner, and Bill Briggs, NASA Ames Research Center, Mountain View, CA) A poster session of multi-scale maps of the Pacific continental margin and Exclusive Economic Zone (EEZ). (Florence Wong, USGS, Menlo Park, CA) Monterey Bay National Marine Sanctuary bathymetric visualization poster session. (Clint Steele, Carolyn Degnan, Michael Hamer, USGS, Menlo Park, CA) A video study of ten years of volcanic eruptions in Alaska including a night view of the eruption of Veniaminof, and day views of Akutan, West Dahl, Augustine, Redoubt and Spur eruptions. (Joseph Dorava, Robert McGimsey, and Mike Doukas, USGS, Anchorage, AK) A demonstration of the scientific visualization applications in Flagstaff showing past, present, and future capabilities using multimedia, CD-ROM, and video techniques. (Dennis McMacken and Lynda Bellisime, USGS, Flagstaff, AZ) A demonstration of the Macintosh digital mapping system computerized mapping process used to generate color separates for thematic maps. (Alex Acosta, USGS, Flagstaff, AZ) Two dimensional animated models of the formation of various ore deposit types that occur around the world. (Dan Mosier, USGS, Menlo Park, CA) Three dimensional animations of the evolution of landforms. (Tau Rho Alpha, USGS, Menlo Park, CA) A discussion of digital orthophotoquads (DOQs) including production, procedures, history, technical overview, and potential applications of this process developed at the Western Mapping Center. (Alan Mikuni and Lyman Ladner, USGS, Menlo Park, CA) A demonstration of the new topographic map production and revision process using digital line graph data (DLGs) and digital orthophotoquads (DOQs) of the Black Earth, Wisconsin 7.5' quadrangle. (Robert Lugo and Liz Wegenka, USGS, Menlo Park, CA) Accomplishments and future goals of the Monterey Bay Modeling Group with particular emphasis on research and public use of scientific visualization data. (Gary Greene, USGS, Menlo Park, CA) The visualization of synoptic topography of the United States, Italy, Sweden, and the Mediterranean by digital shaded relief (Richard Pike, USGS, Menlo Park, CA) Computation of time-series of topographic shading from digital elevation data for modeling temperatures of streams. (Brian Reece, USGS, Carson City, NV) Demonstration of a preliminary multi-agency network for interactive display and query of real-time data. (Tim Liebermann, USGS, Carson City, NV) Earthquakes as they happen: Near-real time epicenter locations via nationwide radio pagers. Displays of plots and text for California, national, and worldwide data. (Barbara Bogaert, USGS; A.L. Jones- SUNY, Bruce Julian, Alex Bittenbinder, and Al Lindh, USGS, Menlo Park, CA) A GIS interface with a particle tracker for a ground-water flow model developed to identify the location of recharge areas, locate contaminant sources, map the down-gradient parts of the flow system, and map the age of ground water throughout the ground- water flow system. (Dan Snyder, James Wilkinson, Leonard Orzol, USGS, Portland, OR) A complex monte carlo simulation model generated debris-flow hazard map of the Honolulu District of Oahu, Hawaii; with a Quicktime animated explanation of the model behind the map. (Bob Mark and Steve Ellen, USGS, Menlo Park, CA) Videotaped documentaries showing the potentially devastating New Madrid seismic zone near Memphis, Tennessee where the most powerful series of earthquakes known occurred in the early 1800s, and the geology of the Pacific Northwest, with particular emphasis on Hells Canyon, Idaho. (Doug Prose, USGS, Menlo Park, CA) A demonstration of the capabilities of Surveyor, an interactive software package used to develop 2-D and 3-D animations. Surveyor can be used to explore extremely large terrain databases and produce animations from these databases, and has been used in collaborative projects undertaken between USGS and JPL. (Kevin Hussey, Dan Stanfill, JPL, Pasadena, CA) A description of the technical preparations and capabilities which allow participating members of the Monterey Bay Modeling Group to view the USGS Scientific Visualization Workshop using the Internet via the Multicast Backbone known as MBONE. (Don Brutzman, Naval Postgraduate School, Monterey, CA) Description of multiple phases of the cooperative international Circumpacific Map Project which is designed to show the relationship of energy and mineral resources to major geologic features of the Pacific Basin and the surrounding continental areas. (George Gryc and Fran Mills, USGS-Menlo Park) Three dimensional shaded relief bathymetric imagery of coastal Central California created by offsetting the red and blue color channels. (Robert Hall, EPA-San Francisco, CA, Jere Swanson and Norman Maher, USGS, Menlo Park, CA) The workshop will take place on September 15 and 16 and the public outreach activity will take place on September 17, 1993. It will be held at the USGS Western Region Headquarters facility in Menlo Park, CA in Conference Facilities A and B, Building 3. Workshop attendance is free. Registration will take place at the door beginning at 7:45am on September 15th. For additional information please contact: Carol Lawson Workshop Coordinator U.S. Geological Survey 345 Middlefield Road, MS870 Menlo Park, CA 94025 (415) 329-4030 clawson@isdmnl.wr.usgs.gov ------------------------------------------------- Frank Terhaar-Yonkers fty@vislab.epa.gov Martin Marietta Technical Services/U.S. EPA Research Triangle Park, North Carolina, U.S. of A. voice - (919)541-2297 fax - (919)541-3967 From rem-conf-request@es.net Thu Sep 02 23:15:13 1993 Received: from recepsen.aa.msen.com by osi-east.es.net via ESnet SMTP service id <12491-0@osi-east.es.net>; Thu, 2 Sep 1993 20:14:30 +0000 Received: from [148.59.6.5] by recepsen.msen.com with smtp (Smail3.1.28.1 #11) id m0oYRb3-000llhC; Thu, 2 Sep 93 23:13 EDT Message-Id: X-Sender: emv@garnet.msen.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 2 Sep 1993 23:22:07 -0800 To: rem-conf@es.net From: emv@mail.msen.com (Edward Vielmetti) Subject: interaction between Cornell's "CU SeeMe" and MBONE Cc: emv@mail.msen.com Can anyone comment on the relationship between Cornell's "CU SeeMe" and the various MBONE tools? Is it for instance possible to tune in an MBONE broadcast via CU SeeMe (through some relay, for instance) or to otherwise connect the video of one to the other? I have the MBONE FAQ which doesn't mention the Cornell package. Alternatively if someone has a spiffy way to get part or all of an MBONE broadcast to a Mac running MacOS, that information would be welcomed too. thanks --Ed Edward Vielmetti, MSEN Inc. emv@msen.com From rem-conf-request@es.net Fri Sep 03 11:07:27 1993 Received: from MITCHELL.CIT.CORNELL.EDU by osi-east.es.net via ESnet SMTP service id <15621-0@osi-east.es.net>; Fri, 3 Sep 1993 08:06:53 +0000 Received: from [132.236.199.54] (PHANTOM.CIT.CORNELL.EDU) by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA19390; Fri, 3 Sep 93 11:06:48 EDT Date: Fri, 3 Sep 93 11:06:47 EDT Message-Id: <9309031506.AA19390@mitchell.cit.cornell.edu> To: rem-conf@es.net, emv@garnet.msen.com (Edward Vielmetti) From: R.Cogger@cornell.edu (Richard Cogger) Sender: rhx@132.236.199.25 Subject: Re: interaction between Cornell's "CU SeeMe" and MBONE Cc: emv@garnet.msen.com So far, the only way CU-SeeMe plays with the mbone is that you can get the video streams from a CU-SeeMe conference mcast onto the mbone and receive them with nv which has a decoder for the purpose. CU-SeeMe uses a unix-based reflector program to make a multiparty conference, and an option on the reflector command-line will cause this relay of video streams. (Of course, the reflector must be running on a machine with the right stuff and connectivity to be an mbone participant.) In the fullness of time, pending getting mcast support for MacTCP, we hope to make CU-SeeMe an mbone participant. Of course, reflectors could be trained to talk with each other via the mbone, and we definitely plan to do that. For Mac's to be able to receive and decode the usual mbone video (from nv), there is the question whether ordinary Mac's have the cycles to decode nv's normal encoding. We've also thought of enhancing the reflector to actually assemble images and potentially re-encode them. Probably the next peice of CU-SeeMe interoperability will be a Windows implementation for use in the current unicast/reflector mode. If I get a chance, I'll try to get this info (and a little more) added to the mbone faq. In the meantime, anyone interested in CU-SeeMe should ftp the README from gated.cornell.edu /pub/video. -Dick At 3:22 AM 9/3/93 -0400, Edward Vielmetti wrote: >Can anyone comment on the relationship between Cornell's "CU SeeMe" and the >various MBONE tools? Is it for instance possible to tune in an MBONE >broadcast via CU SeeMe (through some relay, for instance) or to otherwise >connect the video of one to the other? > >I have the MBONE FAQ which doesn't mention the Cornell package. > >Alternatively if someone has a spiffy way to get part or all of >an MBONE broadcast to a Mac running MacOS, that information would >be welcomed too. > >thanks > >--Ed > >Edward Vielmetti, MSEN Inc. emv@msen.com From rem-conf-request@es.net Fri Sep 03 12:13:27 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <16231-0@osi-east.es.net>; Fri, 3 Sep 1993 08:55:44 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 3 Sep 1993 16:55:33 +0100 To: rem-conf@es.net Subject: time announcement on mbone Date: Fri, 03 Sep 93 16:55:33 +0100 From: Jon Crowcroft i note that sweden is advertising the time on the mbone in the form of a speaking clock could we pursuade dave mills to integrate this with ntp (e.g. carry ntp in rtp packets....and media indicates what lagnauge the data part of the packet is speaking the clock in:-) if this was carried in IP over atm, perhaps we could make sure that the first cell holds the UTC ASN formatted time in rtp header, so if the rest is lost, the receiver could just reconstruct the speaking bit (presumably after adding suitable offset calculated in the normal ntp way, or else vat style...) - also, the session message should indicate timezone and clock source/quality (e.g. MSF, GPS etc etc) alternatively, we might pursuade some natural language researchers to figure out a translation service (including timezone allowances)... cheers jon [not very seriously] From rem-conf-request@es.net Fri Sep 03 21:09:21 1993 Received: from brolga.cc.uq.oz.au by osi-east.es.net via ESnet SMTP service id <21732-0@osi-east.es.net>; Fri, 3 Sep 1993 18:04:33 +0000 Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Sat, 4 Sep 1993 11:04:10 +1000 To: Jon Crowcroft cc: rem-conf@es.net, mills@udel.edu Subject: Re: time announcement on mbone In-reply-to: Your message of "Fri, 03 Sep 1993 16:55:33 +0100." <9309031904.AA27112@wraith.internode.com.au> Date: Sat, 04 Sep 1993 11:04:07 +1000 Message-ID: <10205.747104647@brolga.cc.uq.oz.au> From: George Michaelson Jon, I had the same idea about 4 months ago. My understanding of NTP is that to be truly useful, sender and recipient must both participate in a data exchange to establish end-end delays before useful clock adjustments can be made. If this is NOT the case, and there is a role for NTP to be multicast from some level 0 chimers then I think a VERY SERIOUS case should be made to do so. It might even help with deployment of delay/loss-attuned protocols to establish a common mbone time-tick. then end-end traffic on a per-channel basis wouldn't be needed for a sub-zone of a multicast to take action to correct traffic related behaviour. Damn. I wish I'd spoken up back then and not been the (jon)ny-come-lately.. Mbone heartbeat? Dave, can NTP information be useful in a 1-way dataflow? -George From rem-conf-request@es.net Fri Sep 03 21:28:58 1993 Received: from brolga.cc.uq.oz.au by osi-east.es.net via ESnet SMTP service id <21828-0@osi-east.es.net>; Fri, 3 Sep 1993 18:28:23 +0000 Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Sat, 4 Sep 1993 11:28:09 +1000 To: Jon Crowcroft cc: rem-conf@es.net, mills@udel.edu Subject: Re: time announcement on mbone In-reply-to: Your message of "Fri, 03 Sep 1993 16:55:33 +0100." <9309031904.AA27112@wraith.internode.com.au> Date: Sat, 04 Sep 1993 11:28:05 +1000 Message-ID: <10753.747106085@brolga.cc.uq.oz.au> From: George Michaelson let me re-state my followup more cogently. Say existing UDP based ntp traffic is re-targetted to multicast, and procedures changed to identify a 'recipient' within a (semi)broadcast dataflow so that two clocks can have an end-to-end significant dialogue but now with others watching. Then assuming some backoff or round-robin can be established, all participants of multicast/ntp do their end-to-end dialogue and take globally visible data into account in their clock adjustments. If this is suitably dampened, the multicast clockticks should accurately reflect a global network-time pulse. Thus recieve only references might even become tolerably accurate and permit LESS end-end dialogue to take place. End results: NTP reference data broadcast net-wide. Multicast delay/dispersion stats always available. this might make rate-adaptive protocols more feasible. Not much net change in traffic Maybe even a drop. Shoot me down in flames. -george From rem-conf-request@es.net Fri Sep 03 22:15:56 1993 Received: from nak.Berkeley.EDU by osi-east.es.net via ESnet SMTP service id <22027-0@osi-east.es.net>; Fri, 3 Sep 1993 19:10:24 +0000 Received: from cmsa.Berkeley.EDU by nak.berkeley.edu (5.67/1.40) id AA14215; Fri, 3 Sep 93 19:10:21 -0700 Message-Id: <9309040210.AA14215@nak.berkeley.edu> Received: from cmsa.Berkeley.EDU by cmsa.Berkeley.EDU (IBM VM SMTP V2R2) with BSMTP id 8085; Fri, 03 Sep 93 19:09:57 PDT Received: from CMSA.BERKELEY.EDU (CLIFF) by cmsa.Berkeley.EDU (Mailer R2.08 R208004) with BSMTP id 0372; Fri, 03 Sep 93 19:09:56 PDT Date: Fri, 03 Sep 93 19:09 PDT From: CLIFF@cmsa.Berkeley.EDU (Cliff Frost {510} 642-5360) Subject: Re: time announcement on mbone To: G.Michaelson@cc.uq.oz.au Cc: J.Crowcroft@cs.ucl.ac.uk, rem-conf@es.net, mills@udel.edu In-Reply-To: G.Michaelson at cc.uq.oz.au -- Sat, 04 Sep 1993 11:04:07 +1000 Oh boy! A new area of research! I think the Swedish thing is kool, but lacking a little soul, you know? Ok, so we'll point a camera out the window at the beautiful Berkeley Campanile ("It's chimes are a much loved tradition on the Berkeley Campus"). People all over the world can synchronize their clocks by AI interpretation of an nv picture of the Clock Face. Now, using the Swedish telephone operator's voice, the Berkeley Campanile, and other high-precision time sources strategically deployed for strangulation (cars coming and going from the Bell Labs parking lot? sunrise over unspecified deserts? fish feeding?), we could use the MBONE for the best crock in the known universe! Cliff Frost UC Berkeley From rem-conf-request@es.net Sat Sep 04 08:16:26 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <23971-0@osi-east.es.net>; Sat, 4 Sep 1993 05:11:30 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 4 Sep 1993 13:11:17 +0100 To: George Michaelson cc: rem-conf@es.net, mills@udel.edu Subject: Re: time announcement on mbone - statisical isochrony In-reply-to: Your message of "Sat, 04 Sep 93 11:28:05 +0900." <10753.747106085@brolga.cc.uq.oz.au> Date: Sat, 04 Sep 93 13:11:15 +0100 From: Jon Crowcroft george i thinlk this idea has more than a little merit - an mbone heartbeat is a great idea... jon From rem-conf-request@es.net Mon Sep 06 08:50:36 1993 Received: from mitsou.inria.fr by osi-east.es.net via ESnet SMTP service id <00777-0@osi-east.es.net>; Mon, 6 Sep 1993 05:42:36 +0000 Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA01216; Mon, 6 Sep 1993 14:44:14 +0200 Message-Id: <199309061244.AA01216@mitsou.inria.fr> To: Ron Frederick Cc: Jack Jansen , rem-conf@es.net Subject: Re: Video over slip In-Reply-To: Your message of "Tue, 17 Aug 93 09:17:07 PDT." Date: Mon, 06 Sep 93 14:44:14 +0200 From: Christian Huitema => .... While nv will certainly run fine at this bandwidth, what you => get isn't video but a series of still frames, spaced seconds apart. I know that => ivs is lower bandwidth, but I suspect even it will be less than a frame a => second at this speed, and this just doesn't seem like it will serve the => purpose. For the record. I just tried ivs in QCIF format with the "priviledge frame rate" option and a bandwidth limitation of 17 kbps, in color mode. We get an average of 4 frames per second -- grey mode does not change much. Indeed, the image is far from perfect; selecting the "priviledge quality" mode lets the rate drop at about 1 image per second. Indeed, this is not "full motion video", and your option of recording "the real thing" at a fully connected site was probably better... Christian Huitema PS. This shows that the notion of "frame per second" is in fact quite misleading, and should be somehow ponderated by a "quality of picture" indicator. From rem-conf-request@es.net Mon Sep 06 10:23:09 1993 Received: from faui45.informatik.uni-erlangen.de by osi-east.es.net via ESnet SMTP service id <01006-0@osi-east.es.net>; Mon, 6 Sep 1993 07:14:22 +0000 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA24788 (5.65c-5/7.3v-FAU); Mon, 6 Sep 1993 16:13:17 +0200 Received: from faui45r.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA05333 (5.65c-5/7.3m-FAU); Mon, 6 Sep 1993 16:13:15 +0200 From: Toerless Eckert Message-Id: <199309061413.AA05333@faui43.informatik.uni-erlangen.de> Subject: Re: Video over slip To: Christian Huitema Date: Mon, 6 Sep 93 16:13:09 MET DST Cc: frederic@parc.xerox.com, Jack.Jansen@cwi.nl, rem-conf@es.net In-Reply-To: <199309061244.AA01216@mitsou.inria.fr>; from "Christian Huitema" at Sep 6, 93 2:44 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.3 PL11] > For the record. I just tried ivs in QCIF format with the "priviledge frame > rate" option and a bandwidth limitation of 17 kbps, in color mode. We get an > average of 4 frames per second -- grey mode does not change much. Indeed, the > image is far from perfect; selecting the "priviledge quality" mode lets the > rate drop at about 1 image per second. > > Indeed, this is not "full motion video", and your option of recording "the > real thing" at a fully connected site was probably better... > > Christian Huitema > PS. > This shows that the notion of "frame per second" is in fact quite misleading, > and should be somehow ponderated by a "quality of picture" indicator. WOuld be interesting to see how good it looks if one transfers audio together with the video, but that audio should be compressed very high, say by celp. Does anyone know details about the videophone systems running over normal analog telephone lines ? There's one system from at&t and another that i don't know the manufacturer of. The sound of both is something like celp or gsm and the video is - in my opinion worse than qcif and they get not more than 1 frame every 2 seconds (that's what i've seen). Best regards Toerless From rem-conf-request@es.net Mon Sep 06 13:30:44 1993 Received: from huey.udel.edu by osi-east.es.net via ESnet SMTP service id <01641-0@osi-east.es.net>; Mon, 6 Sep 1993 10:24:44 +0000 Date: Mon, 6 Sep 93 13:16:07 EDT From: Mills@udel.edu To: George Michaelson cc: Jon Crowcroft , rem-conf@es.net, mills@udel.edu Subject: Re: time announcement on mbone Message-ID: <9309061316.aa21608@huey.udel.edu> George, The problem with multicast time is always in the calibration of delay between the transmitter and receiver. The protocol is designed so that, when the transmitter is operating in broadcast mode on the local net, a potential receiver can grab the offset/delay by a client/server call, then settle back and just listen. In principle, the same thing could be done using multicast instead of local-net broadcast. I have proposed previously a scheme much as you suggest. Low-stratum servers would honk their current offset/delay/dispersion with active associations in periodic multicast messages at appropriate intervals. There is enough information in these messages for a listener to both get the time, as well as learn what other servers are about. There is a natural truncation in this scheme, since servers keep persistent state only for those peers of equal or less strata. In point of fact, all this information is already available using the NTP monitoring messages, but not in multicast mode. This may happen real soon now. Dave From rem-conf-request@es.net Mon Sep 06 20:55:57 1993 Received: from twnmoe10.edu.tw by osi-east.es.net via ESnet SMTP service id <03049-0@osi-east.es.net>; Mon, 6 Sep 1993 17:49:56 +0000 Received: from comserv.itri.org.tw by TWNMOE10.Edu.TW (IBM VM SMTP V2R2) with TCP; Tue, 07 Sep 93 08:49:36 EST Received: by comserv.itri.org.tw (ITRI1.0s) from rocky.ccl.itri.org.tw id AA23562; Tue, 7 Sep 93 08:49:20+080 Date: Tue, 7 Sep 93 08:49:20+080 Message-Id: <9309070049.AA23562@comserv.itri.org.tw> Received: by rocky.ccl.itri.org.tw (th3.8wd) id AA08093; Tue, 7 Sep 93 08:47:59 CST From: ujliu@rocky.ccl.itri.org.tw (One-Chin Liu) Apparently-To: rem-conf@es.net Dear Sir: I would very appreciate of subscribing to the mailing list of the Audio-Video Transport WG. My E-mail address is ujliu@nm1.ccl.itri.org.tw Sincerely yours, Uan-Jiun Liu Nework Management System Dept. Computer & Communication Research Laboratories Industrial Technology Research Institute Hsinchu, Taiwan 30043, R. O. C. From rem-conf-request@es.net Mon Sep 06 21:25:25 1993 Received: from paris.ics.uci.edu by osi-east.es.net via ESnet SMTP service id <03151-0@osi-east.es.net>; Mon, 6 Sep 1993 18:18:36 +0000 Received: from valentine.ics.uci.edu by Paris.ics.uci.edu id aa09675; 6 Sep 93 17:12 PDT To: atm@sun.COM, cell-relay@mythos.ucs.indiana.EDU, comp-protocols-tcp-ip@ucbvax.berkeley.EDU, frftc@nsco.network.COM, members@farnet.ORG, nren-discuss@psi.COM, rem-conf@es.NET, smdstc@nsco.network.COM, wireless@tandem.COM, isdn%list.prime.COM@ics.uci.edu Cc: suda@valentine.ICS.UCI.EDU Reply-to: suda@ics.uci.edu Subject: IEEE Comp. Comm. Workshop: Call for Participation Date: Mon, 06 Sep 1993 17:11:33 -0700 From: Tatsuya Suda Message-ID: <9309061712.aa09675@Paris.ics.uci.edu> Dear colleagues: Enclosed is an advance program of the 8th IEEE Workshop on Computer Communications along with a workshop registration form at the end of this message. I hope you will be able to join us in the workshop! Please note that the 6th IEEE Workshop on Local and Metropolitan Area Networks will be held at the same location right before this workshop. TS The 8th IEEE Workshop on Computer Communications IEEE COMMUNICATIONS SOCIETY Technical Committee on Computer Communications Sept.1, 1993 Dear Colleague: I am enclosing the advance technical program and registration materials for the 8th IEEE Workshop on Computer Communications sponsored by the Technical Committee on Computer Communications of the IEEE Communications Society. The workshop will be held October 17-20 at the L'Auberge Del Mar Resort and Spa, Del Mar (San Diego), California. This year we are holding the workshop in conjunction with the Metropolitan Area Network Workshop, October 13-16. This year we will continue to offer special rates for graduate students on a very limited basis. Each application for this rate must be accompanied by a letter by the student's advisor stating his/her qualifications. Only graduate students who are close to completion of a doctoral program and will receive the maximum benefit from the workshop need apply. Students will be selected primarily by postmark date as space allows. The L'Auberge Del Mar Resort and Spa is located in the exclusive seaside village of Del Mar. L'Auberge features 123 luxury guest rooms & suites; European health and beauty spa; fine dining; shopping; championship tennis courts; swimming and lap pools; all with a spectacular ocean view. It is twenty minutes from major San Diego tourist attractions and airport; less than a mile from Del Mar Racetrack. There is a footpath to the beach. It is a Four-star rated hotel recently affiliated with the prestigious Hotel Bel-Air. I am personally looking forward to exploring state of the art technology at this year's workshop with you. I am sure you will enjoy exciting discussions in this luxurious and tranquil setting. Sincerely, Tatsuya Suda Workshop Chair Department of Information and Computer Science University of California, Irvine Irvine, CA 92717-3425 phone: (714) 856-5474 fax: (714) 856-4056 internet: ieeewksp@ics.uci.edu ============================================================================= Technical Program IEEE Communications Society Technical Committee on Computer Communications 8th Annual Computer Communications Workshop L'Auberge Inn at Del Mar (San Diego), California October 17-20, 1993 Oct. 17: Registration Oct. 18-20: Technical Sessions _____________________________________________________________________________ The annual IEEE Computer Communications Workshop is dedicated to informative discussions and presentations of important and timely research in communications. The focus of this year's workshop is on current trends in network technology and management for broadband, optical and wireless networks. As novel technologies and services have begun to evolve toward a wider realization, new research issues have developed. This workshop has been organized to explore these issues in detail, permitting a technical understanding of their interrelatedness and laying a foundation for further research. _____________________________________________________________________________ _____________________________________________________________________________ Sunday, October 17 ____________________________________________________________________________ 5:00pm - 9:00pm Registration Wine & Cheese Reception _____________________________________________________________________________ _____________________________________________________________________________ Monday, October 18 _____________________________________________________________________________ 7:00am Registration Continental Breakfast _____________________________________________________________________________ 8:00am - 10:00am Technical Session I: Measurements of High Speed Networks Organizer: John Daigle (MITRE Corp.) Brief Description: Presentation and discussion of measurements taken from gigabit testbed networks will take place in this session. Tentative Speakers: Gary Minden (U. Kansas) and John Daigle (MITRE Corp.) Existing and Proposed Testing and Measurement in Gigabit Testbed Programs Arne Nilsson (NCSU) Traffic Characteristics in the VISTAnet Allison Mankin (Naval Research Labs) A Comparison of Measurement Results from the BLANCA and NRL High Speed Optical Network -- WANs and LANs Prominent speaker to be added _____________________________________________________________________________ 10:00am - 10:30am Coffee Break _____________________________________________________________________________ 10:30am - 12:30pm Technical Session II: Local Area ATM Organizer: Thomas La Porta (AT&T Bell Labs) Tatsuya Suda (UC Irvine) Brief Description: ATM technologies, although originally targeted for use in wide area, public networks, are rapidly being harnessed by those in the LAN community. ATM's accommodation of high link speeds and multimedia capability have made it attractive in small, high- demand networked environments. Research issues raised by the introduction of ATM technology into the local environment will be discussed in this session. Tentative Speakers: Peter Newman (Adaptive Corp.) LAN Emulation for ATM Networks Vijay Kumar (AT&T Bell Labs) A Multimedia ATM LAN Al Leon-Garcia (U. Toronto) & You-Ze Cho (Kyungpook National University, Korea) Burst-Level Bandwidth Management in Local ATM Networks Thomas La Porta (AT&T Bell Labs) Homogeneous Signaling for ATM LANs, MANs, and WANs Victor Li (USC) and Irfan Khan (SRI Int'l) High Speed Network Traffic Modeling and Management _____________________________________________________________________________ 12:30pm- 2:30pm Lunch _____________________________________________________________________________ 2:30pm - 5:00pm Technical Session III: ATM Performance Issues - (half hour break at 3:30) Supporting Broadband Services Organizers: Jack Brassil (AT&T Bell Labs) Mark Karol (AT&T Bell Labs) Brief Description: B-ISDNs are expected to carry various forms of traffic (voice, video data), each of which places distinct requirements on network transport systems. The purpose of this session is to discuss performance issues associated with supporting various anticipated traffic types. Tentative Speakers: Kai Eng (AT&T Bell Labs) State of the Art in Gigabit ATM Switching Magda El Zarki & Pramod Pancha (U. Pennsylvania) Understanding VBR Video Sources for Transmission over ATM-based Networks Arvind Krishna, Hamid Ahmadi, Moshe Sidi & Khosrow Sohraby (IBM T.J. Watson) Delay and Jitter Analysis in Wireless Environments Izhak Rubin & Ho-Ting Wu(UCLA) Local and Metropolitan ATM Ring Networks: Throughput Capacity and Local Fairness Regulation Hisashi Kobayashi (Princeton) A Diffusion Approximation of ATM Traffic for Statistical Multiplexing _____________________________________________________________________________ 5:30pm Cocktail Party 8:30pm Town Hall Meeting _____________________________________________________________________________ _____________________________________________________________________________ Tuesday, October 19 _____________________________________________________________________________ 7:00am Breakfast _____________________________________________________________________________ 8:00am - 10:00am Technical Session IV: Multicast Communications Organizer: Nachum Shacham (SRI Int'l.) Tentative Speakers: Lixia Zhang (Xerox PARC) RSVP: A Multicast ReSerVation Protocol Mostafa Ammar (Georgia Inst. of Technology) Probabilistic Multicast: Generalizing the Multicast Paradigm to Improve Scalability" Nachum Shacham (SRI Int'l.) Hierarchical Multicast over ATM Deborah Estrin (USC) Wide-area Multicast Routing Support for Sparse Groups _____________________________________________________________________________ 10:00am - 10:30am Coffee Break _____________________________________________________________________________ 10:30am - 12:30pm Technical Session V: Directions in Network Management Organizers: Carl Sunshine (Aerospace Corp.) Joseph Betser (Aerospace Corp.) Brief Description: Network management systems have been evolving rapidly, with competing technologies and many product offerings for both management stations and subnet monitors. Some standards are emerging, but problems of scalability, integration and security remain to be solved. This session will focus on exploring these issues. Tentative Speakers: Joseph Betser (Aerospace Corp.) Current Trends in Technology and Products Mike Erlinger (Harvey Mudd College and Aerospace Corp.) Subnet Monitoring and RMON Steve Waldbusser (CMU) New Developments with SNMP and SNMPv2 Liang Wu (Bellcore) Quality of Service Management in ATM Networks Yechiam Yemini (Columbia U) Management by Delegation _____________________________________________________________________________ 12:30pm- 2:30pm Lunch Break _____________________________________________________________________________ 2:30pm - 5:00pm Technical Session VI: Host Interface Design for (half hour break at 3:30) High Speed Networks Organizer: Sean O'Malley (U. Arizona) Brief Description: As network performance has increased, the network- host interface has emerged as a significant bottleneck in overall network performance. In addition, this increase in network performance has blurred some of the distinctions between WANs, LANs, distributed memory multiprocessor interconnection networks, and intrahost communication channels. Thus the traditional approach to network host interface design appears to provide neither the performance nor the flexibility required by modern computer systems. This session will include presentations of novel approaches to network host interface design. Tentative Speakers: Darleen Fisher (NSF) An Update on Gigabit Network Testbeds Danny Cohen (ISI) The ATOMIC LAN Bruce Davie (Bellcore) The OSIRIS ATM Interface: Experience and Insights Vineet Kumar (Intel) The Intel Paragon HIPPI Interface John Kubiantowicz (MIT LCS) Fast Messaging in the Alewife Multiprocessor David Tennenhouse (MIT LCS) The Design Space for Network Host Interface _____________________________________________________________________________ 6:00pm Dinner Banquet 8:30pm Town Hall Meeting _____________________________________________________________________________ _____________________________________________________________________________ Wednesday, October 20 _____________________________________________________________________________ 7:00am Breakfast _____________________________________________________________________________ 8:00am - 10:00am Technical Session VII: Optical Technology and the Future of Networking Organizers: Joseph Bannister (Aerospace Corp.) Biswanath Mukherjee (UC Davis) Brief Description: Optical technologies will provide the principal foundation for networks of the future. The trends, opportunities, risks and concerns with optical networks will be discussed. Tentative Speakers: Jon Sauer (U. Colorado) Deflection Routing Networks for Computer Interconnection Mario Gerla (UCLA) Cost-Technology Tradeoffs in Multifiber WDM Networks Tony Acampora and Tom Stern (Columbia) All-Optical Network Architectures Based on Wavelength Routing Vincent Chan (Lincoln Labs) Wideband Optical Network of the Future _____________________________________________________________________________ 10:00am - 10:30am Coffee Break _____________________________________________________________________________ 10:30am - 12:30pm Technical Session VIII: Wireless Network Communications Organizer: Khosrow Sohraby (IBM - T.J. Watson) Brief Description: It is expected that, in the future, wireless networks will be supporting a broad range of services such as voice, data, and video. This session will deal with various challenging issues in such networks. Tentative Speaker: Hamid Ahmadi (IBM T.J. Watson) Design Issues for Wireless Local Area Networks S. Nanda (AT&T Bell Labs) A Data Link Protocol for Wireless Links Mahmoud Naghshineh (Columbia) An Architecture and Methodology for Mobile-Executed Cell Hand-off in Wireless ATM Networks Leandros Tassiulas (Polytechnic U.) Efficient Spectrum Management for High Capacity Wireless Networks _____________________________________________________________________________ 12:30pm - 1:00pm Wrap-up Session _____________________________________________________________________________ ============================================================================= REGISTRATION INFORMATION Registration with payment must be received by Monday, September 13, 1993. Registration received after this date cannot be guaranteed acceptance. Please mail or fax a copy of the registration form to: Robin Sharp Phone: (714) 856-5474 IEEE Computer Communications Workshop FAX: (714) 856-4056 Information and Computer Science University of California Irvine, CA 92717-3425 USA Please make checks payable to "IEEE 1993 Computer Communications Workshop". For workshop inquiries, you may contact us through email at: ieeewksp@ics.uci.edu. Cancellations/substitutions must be submitted in writing and received by Monday, September 13, 1993. Workshop fees include workshop attendance, refreshments at breaks, lunches, workshop reception and dinner banquet, and one copy of the conference materials. FEE: $275 *IEEE members $315 Nonmembers $100 Students (subject to approval) *IEEE members must include membership number to receive member discount. ============================================================================= REGISTRATION FORM First Name________________________ Last Name_________________________ Title__________________________________________________________________ Badge Name_____________________________________________________________ Company/Institution____________________________________________________ Address________________________________________________________________ City____________________ State_________ Country__________ Zip__________ Telephone____________________________ Fax______________________________ Email__________________________________________________________________ IEEE Member Number_____________________________________________________ Special Meal Requirements: Vegetarian__________ Kosher__________ Other(Specify)_____________ Amount Enclosed (must be in U.S. dollars) $____________ ============================================================================= The 8th IEEE Workshop on Computer Communications ACCOMMODATION INFORMATION A block of rooms has been reserved at: L'Auberge Del Mar Resort and Spa 1540 Camino Del Mar Del Mar (San Diego), California 92014 Phone: (619) 259-1515 or (800) 553-1336 Fax: (619) 755-4940 The hotel will hold these rooms until October 1, 1993. Hotel arrangements should be made directly to the hotel by phone or the reservation form provided. To receive the special rates (see reservation form), please mention you will be attending the IEEE Computer Communications Workshop. We are holding our workshop in conjunction with the IEEE Metropolitan Area Network Workshop which is being held October 13-16. ----------------------------------------------------------------------------- TRANSPORTATION INFORMATION It is recommended that you fly into San Diego for the easiest access to the workshop location. The San Diego Airport is serviced by all major airlines. If you need assistance with your travel arrangements, the hotel has an on-site travel agency, Ranch and Coast Travel at (619) 481-1230. International travellers may find more convenient flights into Los Angeles Airport. There are also flights available from Los Angeles Airport to San Diego Airport. If you choose not to fly into San Diego Airport from Los Angeles Airport, a rental car is necessary to travel from Los Angeles to the hotel. TRANSPORTATION FROM SAN DIEGO AIRPORT TO L'AUBERGE: Limousine service $40 (4-6 people) phone hotel for arrangements Super Shuttle $25 phone: (619) 278-8877 Taxi $35-40 DIRECTIONS TO L'AUBERGE DEL MAR RESORT AND SPA DIRECTIONS BY CAR: From San Diego Airport From John Wayne (Orange County) Airport (travel time: approximately (travel time: approximately 90 minutes) 20 minutes) and Los Angeles Airport (LAX) (travel time: approximately 3 hrs) Take I-5 North to Del Mar Heights Take 405 Fwy. to I-5 South Road, Take I-5 South to Via De La Valle exit Turn Left (west) on to Del Mar Turn Right (west) on to Jimmy Durante Heights Road, Blvd. (The road will veer left and Follow to Camino Del Mar. turn into Camino Del Mar). Turn Right at light on to Camino L'Auberge is located at the first Del Mar. stop light on the righthand (west) Continue to the intersection Camino side. Del Mar and 15th Street. L'Auberge is located on the westside corner. ============================================================================ L'AUBERGE DEL MAR RESORT AND SPA 1540 CAMINO DEL MAR CALIFORNIA 92014 619-259-1515 Fax-619-755-4940 Nationwide-800-553-1336 HOTEL RESERVATION FORM GROUP NAME: IEEE Communications Society/Technical Committee on Computer Communications Workshop GROUP DATES: OCTOBER 17TH - 21ST, 1993 PLEASE CIRCLE DESIRED ACCOMMODATIONS: $110.00 - Single $120.00 - Single/Garden View $125.00 - Double $130.00 - Double/Garden View $250.00 - Suite $350.00 - Suite ______________________________________________________________________ LAST NAME FIRST NAME PHONE NUMBER ______________________________________________________________________ ADDRESS ARRIVAL DATE:__________ ARRIVAL TIME:________ DEPART. DATE:__________ PLEASE INCLUDE FIRST NIGHT'S DEPOSIT OR CREDIT CARD NUMBER TO CONFIRM YOUR RESERVATION. CREDIT CARD #:______________________________ EXPIRATION DATE:_________ RESERVATIONS RECEIVED PRIOR TO 10/1/93 RECEIVE PRIORITY CONSIDERATION AT L'AUBERGE DEL MAR. RESERVATIONS MADE AFTER THE ABOVE DATE WILL BE ON A SPACE AVAILABILITY BASIS ONLY. SUITES SUBJECT TO AVAILABILITY - PLEASE CALL THE HOTEL DIRECTLY. NO CHARGE FOR CHILDREN 17 OR UNDER IF STAYING IN ROOM WITH PAYING ADULT. RATES ARE SUBJECT TO 10% OCCUPANCY TAX. CHECK-IN TIME IS 4:00PM CHECK-OUT TIME IS 12 NOON. PLEASE CONTACT HOTEL FOR REQUESTS REGARDING EARLY CHECK-IN. ---------------------------------- SIGNATURE ============================================================================ From rem-conf-request@es.net Mon Sep 06 22:23:35 1993 Received: from um.cc.umich.edu by osi-east.es.net via ESnet SMTP service id <03511-0@osi-east.es.net>; Mon, 6 Sep 1993 19:18:16 +0000 Date: Mon, 6 Sep 93 22:18:10 EDT From: Jack.L.DiGiuseppe@um.cc.umich.edu To: rem-conf@es.net Message-ID: <25455903@um.cc.umich.edu> X-MTS-Userid: W4AA Subject: Wayward subscribe request It looks like this message was sent only to me and not the subscribe address! ------- Forwarded message Received: from osi-east.es.net by um.cc.umich.edu via MTS-Net; Mon, 6 Sep 93 21:05:01 EDT Received: from twnmoe10.edu.tw by osi-east.es.net via ESnet SMTP service id <03049-0@osi-east.es.net>; Mon, 6 Sep 1993 17:49:56 +0000 Received: from comserv.itri.org.tw by TWNMOE10.Edu.TW (IBM VM SMTP V2R2) with TCP; Tue, 07 Sep 93 08:49:36 EST Received: by comserv.itri.org.tw (ITRI1.0s) from rocky.ccl.itri.org.tw id AA23562; Tue, 7 Sep 93 08:49:20+080 Date: Tue, 7 Sep 93 08:49:20+080 Message-Id: <9309070049.AA23562@comserv.itri.org.tw> Received: by rocky.ccl.itri.org.tw (th3.8wd) id AA08093; Tue, 7 Sep 93 08:47:59 CST From: ujliu@rocky.ccl.itri.org.tw (One-Chin Liu) Apparently-To: rem-conf@es.net Dear Sir: I would very appreciate of subscribing to the mailing list of the Audio-Video Transport WG. My E-mail address is ujliu@nm1.ccl.itri.org.tw Sincerely yours, Uan-Jiun Liu Nework Management System Dept. Computer & Communication Research Laboratories Industrial Technology Research Institute Hsinchu, Taiwan 30043, R. O. C. From rem-conf-request@es.net Wed Sep 08 09:06:19 1993 Received: from LION.BBN.COM by osi-east.es.net via ESnet SMTP service id <18298-0@osi-east.es.net>; Wed, 8 Sep 1993 05:57:09 +0000 Received: by lion.bbn.com (AA03375); Wed, 8 Sep 93 08:57:01 EDT Date: Wed, 8 Sep 93 08:57:01 EDT From: Bob Clements Message-Id: <9309081257.AA03375@lion.bbn.com> To: rem-conf@es.net Cc: clements@diamond.bbn.com, mills@udel.edu In-Reply-To: Mills@udel.edu's message of Mon, 6 Sep 93 13:16:07 EDT <9309061316.aa21608@huey.udel.edu> Subject: time announcement on mbone I see that the Swedish Speaking Clock is back (not to be confused with the SSC in Texas), and I couldn't resist jumping in with my own version. I've been implementing a WWV-equivalent audio source, complete with 100-Hz subcarrier carrying BCD date/time/DUT1/DST info. My first implementation was over ST-II, and carries RTP/NTP timestamps. The data is sent a second or so early, with timestamps reflecting the correct PLAYOUT time so that the receiver can synchronize local playout with NTP. When the VAT-clock came up, I whipped up a vat-compliant version, which I'm now running from time to time, on the same channel as the SSC. Although the VAT timestamps I'm sending are also NTP-correlated, VAT doesn't know that and doesn't try to play them at the true time. Also, since many of the seconds in the WWV code have no audio for the trailing .2, .5 or .8 seconds, I send each such second as a talkspurt. This leads to VAT readjusting the playout interval at every second, and thus uneven seconds-tick timing. None of this is meant as a criticism of VAT. It wasn't meant for this use. I think this program will be a useful too for RTP over ST and RTP over IP testing. My clock uses most of the 64 kHz channel, so I won't leave it running all the time. (Anyone wanting to try a short unicast test is welcome, just send me a note. At present the program doesn't respond automatically to connect requests.) Bob Clements, K1BC, clements@bbn.com (announcer for pseudo-WWV hack, too) From rem-conf-request@es.net Wed Sep 08 13:21:18 1993 Received: from ohm.ee.utulsa.edu by osi-east.es.net via ESnet SMTP service id <20552-0@osi-east.es.net>; Wed, 8 Sep 1993 10:15:28 +0000 Received: from neon.ee.utulsa.edu by ohm.ee.utulsa.edu (4.1/SMI-DDN(15oct91)) id AA03680; Wed, 8 Sep 93 12:15:02 CDT Date: Wed, 8 Sep 93 12:15:02 CDT From: rga@ohm.ee.utulsa.edu (Robert Arnold) Message-Id: <9309081715.AA03680@ohm.ee.utulsa.edu> To: rem-conf-request@es.net, rem-conf@es.net Subject: change of address Cc: jgk@ohm.ee.utulsa.edu Please remove me from the rem-conf distribution list. I am very interested but am about to drown in information.... Please add a new user in my place -- video@ohm.ee.utulsa.edu Thanx Dr. Robert G. Arnold Assoc Prof, EE Dept Univ of Tulsa Tulsa, Ok rga@ohm.ee.utulsa.edu From rem-conf-request@es.net Wed Sep 08 22:09:25 1993 Received: from research.att.com by osi-east.es.net via ESnet SMTP service id <25832-0@osi-east.es.net>; Wed, 8 Sep 1993 18:58:05 +0000 From: kanakia@research.att.com Date: Wed, 8 Sep 93 21:57:55 EDT To: rem-conf@es.net The following paper (being presented in SIGCOMM'93) examines whys and hows of using network-generated feedback for real-time packet video. To get a copy of the paper, ftp "anonymous"ly from research.att.com the postscript file dist/video.ps.Z A useful paper, if you have a reason to doubt leaky buckets and/or coloring schemes, or just don't want to use complex scheduling mechanisms at a switch:-):-). Comments are welcome. Hemant Kanakia ---------------------------- An Adaptive Congestion Control Scheme for Real-Time Packet Video Transport by Hemant Kanakia, Partho Mishra and Amy Reibman AT\&T Bell Laboratories, Murray Hill, New Jersey kanakia@research.att.com partho@research.att.com amy@vax135.att.com ABSTRACT: In this paper we show that modulating the source rate of a video encoder based on feedback information from the network results in graceful degradation in picture quality during periods of congestion. Such source rate modulation techniques have been used in the past in designing video encoders used to generate data at a fixed rate. In such constant bit rate encoders, the source rate modulation is done using feedback information about the occupancy of a local buffer. Since the buffer is local, the feedback information is available instantaneously to the encoder. In the proposed scheme, the feedback information is delayed because it comes from within a packet-switching network. The feedback provides information about the traffic at switches along the path of the video connection. We show that the proposed scheme performs well, even though the information is delayed for relatively large intervals of time. We believe that the use of such schemes will simplify the architecture used for supporting real-time services in future nationwide gigabit networks. From rem-conf-request@es.net Thu Sep 09 08:55:21 1993 Received: from sics.se by osi-east.es.net via ESnet SMTP service id <28818-0@osi-east.es.net>; Thu, 9 Sep 1993 05:47:18 +0000 Received: from bugs.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA05718; Thu, 9 Sep 93 14:47:15 +0200 Message-Id: <9309091247.AA05718@sics.se> To: rem-conf@es.net Subject: new time announcer Date: Thu, 09 Sep 1993 14:47:14 +0200 From: Anders Klemets I have now added a time announcer that speaks Swedish as well to that vat channel. This one is more sophisticated than the English language one because it transmits a beep exactly when the number of seconds is a multiple of 10. It does not take the transmission and playout delays into account, however. Maybe you could use this fact to estimate the cumulative size of those delays between my site and yours. Anders From rem-conf-request@es.net Thu Sep 09 10:10:23 1993 Received: from bnl.gov by osi-east.es.net via ESnet SMTP service id <29380-0@osi-east.es.net>; Thu, 9 Sep 1993 07:08:53 +0000 Received: by bnl.gov (5.57/Ultrix3.0-C) id AA08520; Thu, 9 Sep 93 10:08:50 -0400 Received: by maeva.ccd.bnl.gov.ccd.bnl.gov (5.0/SMI-SVR4) id AA09295; Thu, 9 Sep 93 10:08:48 EDT Date: Thu, 9 Sep 93 10:08:48 EDT From: gc@maeva.ccd.bnl.gov (Graham Campbell) Message-Id: <9309091408.AA09295@maeva.ccd.bnl.gov.ccd.bnl.gov> To: rem-conf@es.net Subject: Remote display of nv X-Sun-Charset: US-ASCII Content-Length: 391 I have just tried to display nv output remotely (via setenv DISPLAY) on a black and white display. All I get is a varying pattern of vertical bars, like a changing bar-code. Is this behaviour understood? Details. The originating system is a Sun IPC with a color monitor running Solaris 2.2. The displaying system is a Sun ELC with a black and white monitor running SunOS 4.1.1. Graham From rem-conf-request@es.net Thu Sep 09 14:58:27 1993 Received: from alw.nih.gov by osi-east.es.net via ESnet SMTP service id <02704-0@osi-east.es.net>; Thu, 9 Sep 1993 11:46:52 +0000 Received: from kirin.dcrt.nih.gov by alw.nih.gov (5.61/1.35(alw-2.4)) id AA11254; Thu, 9 Sep 93 14:46:46 -0400 Received: by kirin.dcrt.nih.gov (4.1/3.15) id for gc@maeva.ccd.bnl.gov; Thu, 9 Sep 93 14:46:45 EDT Received: via switchmail; Thu, 9 Sep 1993 14:46:45 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Thu, 9 Sep 1993 14:46:18 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Thu, 9 Sep 1993 14:46:17 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.dude.dcrt.nih.gov.sun4c.411 via MS.5.6.dude.dcrt.nih.gov.sun4_41; Thu, 9 Sep 1993 14:46:16 -0400 (EDT) Message-Id: <4gXrbsm0ts4jQ1kmUn@alw.nih.gov> Date: Thu, 9 Sep 1993 14:46:16 -0400 (EDT) From: Bob Dew Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rem-conf@es.net, gc@maeva.ccd.bnl.gov (Graham Campbell) Subject: Re: Remote display of nv In-Reply-To: <9309091408.AA09295@maeva.ccd.bnl.gov.ccd.bnl.gov> References: <9309091408.AA09295@maeva.ccd.bnl.gov.ccd.bnl.gov> > I have just tried to display nv output remotely (via setenv DISPLAY) on > a black and white display. All I get is a varying pattern of vertical bars, like a changing bar-code. Is this behaviour understood? While nv itself takes up relatively little bandwidth on our network, we've discovered that a single remote display session, like what you describe, will totally flood the subnet, bringing it to a hault in short order. I'm not sure why this happens. Bob From rem-conf-request@es.net Thu Sep 09 16:15:07 1993 Received: from alpha.Xerox.COM by osi-east.es.net via ESnet SMTP service id <03607-0@osi-east.es.net>; Thu, 9 Sep 1993 13:07:53 +0000 Received: from reynaldo.parc.xerox.com ([13.2.116.96]) by alpha.xerox.com with SMTP id <12577>; Thu, 9 Sep 1993 13:01:35 -0700 Received: by reynaldo.parc.xerox.com id <25545>; Thu, 9 Sep 1993 13:01:30 -0700 From: Berry Kercheval To: Bob Dew Cc: gc@maeva.ccd.bnl.gov (Graham Campbell), rem-conf@es.net Subject: Re: Remote display of nv In-Reply-To: <4gXrbsm0ts4jQ1kmUn@alw.nih.gov> References: <4gXrbsm0ts4jQ1kmUn@alw.nih.gov> <9309091408.AA09295@maeva.ccd.bnl.gov.ccd.bnl.gov> Reply-To: kerch@parc.xerox.com Message-Id: <93Sep9.130130pdt.25545@reynaldo.parc.xerox.com> Date: Thu, 9 Sep 1993 13:01:16 -0700 Bob Dew writes: > While nv itself takes up relatively little bandwidth on our network, > we've discovered that a single remote display session, like what you > describe, will totally flood the subnet, bringing it to a hault in short > order. I'm not sure why this happens. Because nv does frame differencing and compression to minimize the data actually transmitted, while the X connection to a remote display will send ALL the bits, EVERY frame.... ick! --berry From rem-conf-request@es.net Thu Sep 09 16:19:17 1993 Received: from alpha.Xerox.COM by osi-east.es.net via ESnet SMTP service id <03685-0@osi-east.es.net>; Thu, 9 Sep 1993 13:12:38 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <12440>; Thu, 9 Sep 1993 13:10:34 -0700 Received: by ecco.parc.xerox.com id <16136>; Thu, 9 Sep 1993 13:10:29 -0700 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.ecco.parc.xerox.com.sun4.41 via MS.5.6.ecco.parc.xerox.com.sun4_41; Thu, 9 Sep 1993 13:10:14 -0700 (PDT) Message-ID: Date: Thu, 9 Sep 1993 13:10:14 -0700 Sender: Ron Frederick From: Ron Frederick To: Bob Dew Subject: Re: Remote display of nv CC: rem-conf@es.net In-Reply-To: <4gXrbsm0ts4jQ1kmUn@alw.nih.gov> References: <9309091408.AA09295@maeva.ccd.bnl.gov.ccd.bnl.gov> <4gXrbsm0ts4jQ1kmUn@alw.nih.gov> > While nv itself takes up relatively little bandwidth on our network, > we've discovered that a single remote display session, like what you > describe, will totally flood the subnet, bringing it to a hault in short > order. I'm not sure why this happens. This is unavoidable. When you run nv this way, you're sending completely uncompressed images across the net using the X protocol (XPutImage). So, all the advantages of nv's compression are lost. Even for small images and relatively low frame rates, it's easy for this to use up several megabits/sec. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Thu Sep 09 16:20:17 1993 Received: from alpha.Xerox.COM by osi-east.es.net via ESnet SMTP service id <03708-0@osi-east.es.net>; Thu, 9 Sep 1993 13:14:34 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <12375>; Thu, 9 Sep 1993 13:13:24 -0700 Received: by ecco.parc.xerox.com id <16136>; Thu, 9 Sep 1993 13:13:15 -0700 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.ecco.parc.xerox.com.sun4.41 via MS.5.6.ecco.parc.xerox.com.sun4_41; Thu, 9 Sep 1993 13:13:13 -0700 (PDT) Message-ID: Date: Thu, 9 Sep 1993 13:13:13 -0700 Sender: Ron Frederick From: Ron Frederick To: gc@maeva.ccd.bnl.gov (Graham Campbell) Subject: Re: Remote display of nv CC: rem-conf@es.net In-Reply-To: <9309091408.AA09295@maeva.ccd.bnl.gov.ccd.bnl.gov> References: <9309091408.AA09295@maeva.ccd.bnl.gov.ccd.bnl.gov> > I have just tried to display nv output remotely (via setenv DISPLAY) > on a black and white display. All I get is a varying pattern of vertical > bars, like a changing bar-code. Is this behaviour understood? How recent is your version of nv? The latest is 3.2. There have been bugs in the monochrome support on some earlier releases. Also, the 1-bit deep thumbnail images that show up in nv's main window are pretty pathetic. There simply isn't enough resolution to do anything there. Even the larger images don't look great, but you should be able to make out who the person is. As Bob Dew pointed out, it's a really bad idea to run nv remotely like this, though. While it works, it's incredibly unfriendly to your local net. You should try and run nv on the same machine you are displaying on. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Thu Sep 09 16:21:58 1993 Received: from alpha.Xerox.COM by osi-east.es.net via ESnet SMTP service id <03832-0@osi-east.es.net>; Thu, 9 Sep 1993 13:21:14 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <12422>; Thu, 9 Sep 1993 13:20:25 -0700 Received: by ecco.parc.xerox.com id <16136>; Thu, 9 Sep 1993 13:20:16 -0700 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.ecco.parc.xerox.com.sun4.41 via MS.5.6.ecco.parc.xerox.com.sun4_41; Thu, 9 Sep 1993 13:20:11 -0700 (PDT) Message-ID: <4gXszvIB0bH4M3mXxZ@ecco.parc.xerox.com> Date: Thu, 9 Sep 1993 13:20:11 -0700 Sender: Ron Frederick From: Ron Frederick To: Toerless Eckert Subject: Re: Video over slip CC: rem-conf@es.net In-Reply-To: <199309061413.AA05333@faui43.informatik.uni-erlangen.de> References: <199309061413.AA05333@faui43.informatik.uni-erlangen.de> > Does anyone know details about the videophone systems running over > normal analog telephone lines ? There's one system from at&t and > another that i don't know the manufacturer of. The sound of both is > something like celp or gsm and the video is - in my opinion worse than > qcif and they get not more than 1 frame every 2 seconds (that's what > i've seen). Yes - this matches with my experience. They're about QCIF in terms of number of pixels, but very blurry, and that frame rate was about what I saw as well. I also noticed that the video seemed to slow down when speech was present. I got the feeling that they were tossing in video data during silences (or at least giving video more bandwidth at that time). The synchronization was also much worse than what I've seen across the Internet... -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Thu Sep 09 16:30:11 1993 Received: from alpha.Xerox.COM by osi-east.es.net via ESnet SMTP service id <03863-0@osi-east.es.net>; Thu, 9 Sep 1993 13:24:52 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <12269>; Thu, 9 Sep 1993 13:24:26 -0700 Received: by ecco.parc.xerox.com id <16136>; Thu, 9 Sep 1993 13:24:21 -0700 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.ecco.parc.xerox.com.sun4.41 via MS.5.6.ecco.parc.xerox.com.sun4_41; Thu, 9 Sep 1993 13:24:15 -0700 (PDT) Message-ID: <0gXt3j4B0bH403mYVM@ecco.parc.xerox.com> Date: Thu, 9 Sep 1993 13:24:15 -0700 Sender: Ron Frederick From: Ron Frederick To: Christian Huitema Subject: Re: Video over slip CC: rem-conf@es.net In-Reply-To: <199309061244.AA01216@mitsou.inria.fr> References: <199309061244.AA01216@mitsou.inria.fr> Christian writes: > > [differences about "privilege frame rate" & "privilege quality" deleted] > > This shows that the notion of "frame per second" is in fact quite > misleading, and should be somehow ponderated by a "quality of picture" > indicator. Yes - I agree. It would be interesting sometime to actually try and measure something like RMS error introduced by the compression, or something else which quantifies the artifacts introduced. This is difficult to do, as the amount of displeasure a particular artifact causes is very subjective. I'm sure there has been research done into what measurements give reasonably useful results, though. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Thu Sep 09 17:26:04 1993 Received: from sadye.emba.uvm.edu by osi-east.es.net via ESnet SMTP service id <04790-0@osi-east.es.net>; Thu, 9 Sep 1993 14:19:58 +0000 Received: by sadye.emba.uvm.edu id AA21831 (5.65/1.23); Thu, 9 Sep 93 17:19:26 -0400 Date: Thu, 9 Sep 93 17:19:26 -0400 From: wollman@uvm-gen.EMBA.UVM.EDU Message-Id: <9309092119.AA21831@sadye.emba.uvm.edu> To: Ron Frederick Cc: gc@maeva.ccd.bnl.gov (Graham Campbell), rem-conf@es.net Subject: Re: Remote display of nv In-Reply-To: References: <9309091408.AA09295@maeva.ccd.bnl.gov.ccd.bnl.gov> < said: > As Bob Dew pointed out, it's a really bad idea to run nv remotely like > this, though. While it works, it's incredibly unfriendly to your local net. But X is running over TCP, and everybody's TCP has VJCC, right? I have run nv on my X terminal before and it is not that bad. Unfortunately, this particular X terminal (IBM Xstation 130) has problems with either memory compaction or some sort of resource leak, so if I run nv in a full window it rapidly runs out of memory and I have to reboot the thing. (I haven't tried this since we installed the new X11R5 server, so I don't know if it has gotten any better. My intuition says unlikely.) -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant From rem-conf-request@es.net Thu Sep 09 17:26:45 1993 Received: from POSTOFFICE.MAIL.CORNELL.EDU by osi-east.es.net via ESnet SMTP service id <04889-0@osi-east.es.net>; Thu, 9 Sep 1993 14:25:03 +0000 Received: from [132.236.195.71] by postoffice.mail.cornell.edu with SMTP id AA25912 (5.65c8/IDA-1.4.4 for rem-conf@es.net); Thu, 9 Sep 1993 17:24:54 -0400 Message-Id: <199309092124.AA25912@postoffice.mail.cornell.edu> X-Sender: swb1@postoffice.mail.cornell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 9 Sep 1993 17:25:01 -0400 To: Ron Frederick From: Scott W Brim Subject: Re: Video over slip Cc: rem-conf@es.net >This is >difficult to do, as the amount of displeasure a particular artifact causes >is very subjective. I would like to understand which particular lossy-but-quick-and-high compression techniques are the most tolerable (subjectively, psychologically) in video, and to adopt one of them for low-bandwidth environments. From rem-conf-request@es.net Fri Sep 10 03:54:54 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <09509-0@osi-east.es.net>; Fri, 10 Sep 1993 00:46:59 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 10 Sep 1993 08:46:44 +0100 To: Ron Frederick cc: Bob Dew , rem-conf@es.net Subject: Re: Remote display of nv In-reply-to: Your message of "Thu, 09 Sep 93 13:10:14 PDT." Date: Fri, 10 Sep 93 08:46:42 +0100 From: Jon Crowcroft >This is unavoidable. When you run nv this way, you're sending >completely uncompressed images across the net using the X protocol >(XPutImage). So, all the advantages of nv's compression are lost. Even >for small images and relatively low frame rates, it's easy for this to use >up several megabits/sec. Ron one of these days the next generation window system will support video as a first class data type and compressed video as some sub-type, and then maybe mobile nv reception would become quite easty (he said glibly:-) jon From rem-conf-request@es.net Fri Sep 10 09:35:29 1993 Received: from s1.msi.umn.edu by osi-east.es.net via ESnet SMTP service id <11042-0@osi-east.es.net>; Fri, 10 Sep 1993 06:25:06 +0000 Received: from i5.msi.umn.edu by s1.msi.umn.edu; Fri, 10 Sep 93 08:25:02 -0500 From: hughes@s1.msi.umn.edu Message-Id: <9309101325.AA01582@i5.msi.umn.edu> Received: by i5.msi.umn.edu; Fri, 10 Sep 93 08:25:01 -0500 Subject: Re: Remote display of nv To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Fri, 10 Sep 1993 08:25:01 -0600 (CDT) Cc: frederic@parc.xerox.com, rdew@alw.nih.gov, rem-conf@es.net In-Reply-To: <199309100810.AA13733@spruce.cic.net> from "Jon Crowcroft" at Sep 10, 93 08:46:42 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 614 According to Jon Crowcroft: > one of these days the next generation window system will support video > as a first class data type and compressed video as some sub-type, and > then maybe mobile nv reception would become quite easty (he said > glibly:-) Doesn't X11R6 already have support for this? -- Matthew V. Hughes - MN Supercomputer Institute Graphics Support Coordinator Minnesota Supercomputer Center, Inc. Ph: (612) 626-1765 1200 Washington Avenue South hughes@msc.edu hughes@msi.umn.edu WWWeb home: Minneapolis, MN 55415 From rem-conf-request@es.net Fri Sep 10 10:50:42 1993 Received: from alw.nih.gov by osi-east.es.net via ESnet SMTP service id <11544-0@osi-east.es.net>; Fri, 10 Sep 1993 07:41:16 +0000 Received: from kirin.dcrt.nih.gov by alw.nih.gov (5.61/1.35(alw-2.4)) id AA19660; Fri, 10 Sep 93 10:41:11 -0400 Received: by kirin.dcrt.nih.gov (4.1/3.15) id for gc@maeva.ccd.bnl.gov; Fri, 10 Sep 93 10:41:10 EDT Received: via switchmail; Fri, 10 Sep 1993 10:41:09 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Fri, 10 Sep 1993 10:39:50 -0400 (EDT) Received: from dude.dcrt.nih.gov via qmail ID ; Fri, 10 Sep 1993 10:39:42 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.dude.dcrt.nih.gov.sun4c.411 via MS.5.6.dude.dcrt.nih.gov.sun4_41; Fri, 10 Sep 1993 10:39:41 -0400 (EDT) Message-Id: <4gY96hi0ts4j81ks4r@alw.nih.gov> Date: Fri, 10 Sep 1993 10:39:41 -0400 (EDT) From: Bob Dew Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: kerch@parc.xerox.com Subject: Re: Remote display of nv Cc: gc@maeva.ccd.bnl.gov (Graham Campbell), rem-conf@es.net In-Reply-To: <93Sep9.130130pdt.25545@reynaldo.parc.xerox.com> References: <4gXrbsm0ts4jQ1kmUn@alw.nih.gov> <9309091408.AA09295@maeva.ccd.bnl.gov.ccd.bnl.gov> <93Sep9.130130pdt.25545@reynaldo.parc.xerox.com> > Because nv does frame differencing and compression to minimize the > data actually transmitted, while the X connection to a remote display > will send ALL the bits, EVERY frame.... ick! > --berry Granted, nv does frame differencing and compression at the transmission source. But that results in a throttled update rate at the display end. Certainly not all of a display image's pixels are updated during each frame refresh, are they? If not, why would X need to transmit entire frames several times each second? Bob From rem-conf-request@es.net Fri Sep 10 15:26:03 1993 Received: from alpha.Xerox.COM by osi-east.es.net via ESnet SMTP service id <14925-0@osi-east.es.net>; Fri, 10 Sep 1993 12:20:37 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <11678>; Fri, 10 Sep 1993 12:09:10 -0700 Received: by ecco.parc.xerox.com id <16136>; Fri, 10 Sep 1993 12:09:07 -0700 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.ecco.parc.xerox.com.sun4.41 via MS.5.6.ecco.parc.xerox.com.sun4_41; Fri, 10 Sep 1993 12:08:52 -0700 (PDT) Message-ID: <0gYB34IB0bH483mjkR@ecco.parc.xerox.com> Date: Fri, 10 Sep 1993 12:08:52 -0700 Sender: Ron Frederick From: Ron Frederick To: kerch@parc.xerox.com, Bob Dew Subject: Re: Remote display of nv CC: gc@maeva.ccd.bnl.gov (Graham Campbell), rem-conf@es.net In-Reply-To: <4gY96hi0ts4j81ks4r@alw.nih.gov> References: <4gXrbsm0ts4jQ1kmUn@alw.nih.gov> <9309091408.AA09295@maeva.ccd.bnl.gov.ccd.bnl.gov> <93Sep9.130130pdt.25545@reynaldo.parc.xerox.com> <4gY96hi0ts4j81ks4r@alw.nih.gov> > Granted, nv does frame differencing and compression at the > transmission source. But that results in a throttled update rate at the > display end. Certainly not all of a display image's pixels are updated > during each frame refresh, are they? If not, why would X need to > transmit entire frames several times each second? Because of the overhead of the requests, and the fact that the requests can only be rectangles, nv currently does transmit the entire frame to the X server on a frame end. The alternative would either be to send each 8x8 block or row of blocks as a separate PutImage, which would be very inefficient, or try to come up with some compromise where larger rectangles could be coalesced when it made sense, but it didn't have to update the entire frame, and it isn't clear it is worth the overhead to compute that. In the local machine case, a shared memory area is used when possible, so none of the data actually ends up going over the X connection at all... -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Mon Sep 13 05:44:18 1993 Received: from ibminet.awdpa.ibm.com by osi-east.es.net via ESnet SMTP service id <26642-0@osi-east.es.net>; Mon, 13 Sep 1993 02:34:26 +0000 Received: by ibminet.awdpa.ibm.com (5.61/1.15) id AA16490; Mon, 13 Sep 93 02:34:54 -0700 Received: by ibmpa.awdpa.ibm.com (5.65b(em1)/2.06) id AA08989; Mon, 13 Sep 93 02:33:10 -0700 From: schaller@ibmpa.awdpa.ibm.com (Sibylle Schaller) Message-Id: <9309130933.AA08989@ibmpa.awdpa.ibm.com> Subject: append to mailing list To: rem-conf@es.net Date: Mon, 13 Sep 1993 02:33:08 -0700 (PDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 139 Hallo, would you please add me to the rem-conf mailing list? My address is: schaller@ibmpa.awdpa.ibm.com Thank you, Sibylle Schaller From rem-conf-request@es.net Mon Sep 13 15:16:21 1993 Received: from alpha.Xerox.COM by osi-east.es.net via ESnet SMTP service id <01573-0@osi-east.es.net>; Mon, 13 Sep 1993 12:10:37 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <11671(5)>; Mon, 13 Sep 1993 12:09:56 PDT Received: by ecco.parc.xerox.com id <16136>; Mon, 13 Sep 1993 12:09:48 -0700 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.ecco.parc.xerox.com.sun4.41 via MS.5.6.ecco.parc.xerox.com.sun4_41; Mon, 13 Sep 1993 12:09:40 -0700 (PDT) Message-ID: Date: Mon, 13 Sep 1993 12:09:40 PDT Sender: Ron Frederick From: Ron Frederick To: Scott W Brim Subject: Re: Video over slip CC: rem-conf@es.net In-Reply-To: <199309092124.AA25912@postoffice.mail.cornell.edu> References: <199309092124.AA25912@postoffice.mail.cornell.edu> Scott Brim writes: > I would like to understand which particular lossy-but-quick-and-high > compression techniques are the most tolerable (subjectively, > psychologically) in video, and to adopt one of them for low-bandwidth > environments. Yes -- this is definitely one of the directions I pursued for a while in nv, with each major release changing the video compression to try and reduce the offensiveness of the artifacts. I suspect at this point that you still consider nv to violate the "quick" criterion, since my development target was workstations rather than PCs/Macs. I do actually have a scheme in mind which should produce very similar artifacts (and probably compression ratio) but reduce the cost of the compression by another factor of 2. I haven't had a chance to try it yet. I'm also not entirely happy with my compression ratio yet. I'd like to get the bandwidth requirements down a bit further, as I'd like to be able to take advantage of the faster frame grabbers out there and up the frame rate some while still running at 128kbps or less. Of course, trying to keep the quality the same while increasing the compression ratio is difficult without making the algorithm more expensive computationally... If anyone out there has ideas for video compression schemes that run quickly in software on general purpose architectures, I'd love to hear them. I already support a few different compression schemes on the nv decode side, and I'm looking to evolve the encode side some more... -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Mon Sep 13 17:29:49 1993 Received: from galaxy.net.Hawaii.Edu by osi-east.es.net via ESnet SMTP service id <03179-0@osi-east.es.net>; Mon, 13 Sep 1993 14:23:10 +0000 Received: from dorsai.net.Hawaii.Edu ([132.160.3.4]) by galaxy.net.Hawaii.Edu with SMTP id <119813>; Mon, 13 Sep 1993 11:22:57 -1000 Date: Mon, 13 Sep 1993 11:16:40 -1000 From: Winston KC Dang Subject: DEC version of IMM 2.6 available To: rem-conf@es.net, mbone@ISI.EDU, torben@Hawaii.Edu, Fred Templin In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A DEC version of IMM 2.6 is now available at ftp.hawaii.edu: /ftp/paccom/imm-2.6/bin. Many thanks to Fred Templin who ported it. Winston Dang From rem-conf-request@es.net Mon Sep 13 19:47:56 1993 Received: from mothra.nts.uci.edu by osi-east.es.net via ESnet SMTP service id <04974-0@osi-east.es.net>; Mon, 13 Sep 1993 16:47:22 +0000 Received: by mothra.nts.uci.edu id AA02054 (5.65c/IDA-1.4.4 for rem-conf@es.net); Mon, 13 Sep 1993 16:47:18 -0700 Received: from [128.200.132.104] (godzilla.nts.uci.edu) by mothra.nts.uci.edu with SMTP id AA02041 (5.65c/IDA-1.4.4 for rem-conf@es.net); Mon, 13 Sep 1993 16:47:00 -0700 Message-Id: <199309132347.AA02041@mothra.nts.uci.edu> Date: Mon, 13 Sep 1993 16:50:20 -0800 To: Ron Frederick , Scott W Brim From: David Walker X-Sender: dhwalker@mothra.nts.uci.edu Subject: Re: Video over slip Cc: rem-conf@es.net Ron, At 12:09 PM 9/13/93 -0700, Ron Frederick wrote: ... >I'm also not entirely happy with my compression ratio yet. I'd like to get >the bandwidth requirements down a bit further, as I'd like to be able to >take advantage of the faster frame grabbers out there and up the frame >rate some while still running at 128kbps or less. Of course, trying to keep >the quality the same while increasing the compression ratio is difficult >without making the algorithm more expensive computationally... For your consideration... I've gotten the comment (from a high-level campus administrator) that it would be nice to have a lower-quality mode that achieves a higher frame rate. It seems to me that this could be a reasonable compromise for many applications of nv, given that many of the cameras are not very high quality, anyway. If all one wants is the general sense of a person's face while that person is talking, a little graininess would be fine. David Walker Assistant Director, ECS Office of Academic Computing Addresses: Electronic Communication Services University of California Irvine, CA 92717-5475 (714) 856-7037 (714) 725-2270 (FAX) DHWalker@uci.edu From rem-conf-request@es.net Mon Sep 13 23:35:21 1993 Received: from POSTOFFICE.MAIL.CORNELL.EDU by osi-east.es.net via ESnet SMTP service id <06146-0@osi-east.es.net>; Mon, 13 Sep 1993 20:30:00 +0000 Received: from [132.236.236.57] (CU-DIALUP-0215.CIT.CORNELL.EDU) by postoffice.mail.cornell.edu with SMTP id AA15963 (5.65c8/IDA-1.4.4 for rem-conf@es.net); Mon, 13 Sep 1993 23:29:35 -0400 Message-Id: <199309140329.AA15963@postoffice.mail.cornell.edu> X-Sender: swb1@postoffice.mail.cornell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Sep 1993 23:29:41 -0400 To: Ron Frederick From: Scott W Brim Subject: Re: Video over slip Cc: rem-conf@es.net >Of course, trying to keep >the quality the same while increasing the compression ratio is difficult >without making the algorithm more expensive computationally. That's where "dirty" comes in, when you can't squeeze much more out of "quick". As we've all demonstrated, lousy video is extraordinarily useful when compared to no video at all. The human brain does a lot of interpolation of visual information. Psychologically and physiologically, what aspects of video can be absent, or erroneous, and still have the video be tolerable to the viewer? Which of these aspects can be dropped with the least degradation of the viewer's subjective experience? Which ones offer the greatest relief in processing overhead and bandwidth requirement? Beats me. I don't know the literature on this, since I haven't had time to follow up on any of these questions. I really think it's worth pursuing, though. Scott From rem-conf-request@es.net Tue Sep 14 09:08:53 1993 Received: from fs1.cam.nist.gov by osi-east.es.net via ESnet SMTP service id <08804-0@osi-east.es.net>; Tue, 14 Sep 1993 05:58:47 +0000 Received: from muon.nist.gov by fs1.cam.nist.gov (4.1/SMI-DDN) id AA19533; Tue, 14 Sep 93 08:58:45 EDT Received: by muon.nist.gov (4.1/SMI-4.1-MHS-7.0) id AA07791; Tue, 14 Sep 93 08:58:59 EDT Date: Tue, 14 Sep 93 08:58:59 EDT From: chang@muon.nist.gov (Wo_Chang_x3439) Message-Id: <9309141258.AA07791@muon.nist.gov> To: rem-conf@es.net, mbone@isi.edu Subject: workstation for mbone Cc: wchang@nist.gov Hi All, [Sorry, some of you maybe on both mailing lists, my apology. ] I'm sure this is the most FAQ, but let me ask one more time: 1) Which workstation [ready to use for mbone multicast -- no need to modify the kernel; its system configuration and network environment (FDDI or Ethernet)] will produce the best performance (higher frame rate/sec, more continous audio) for both transmitting and receiving audio/video over the mbone? 2) At what ttl can one setup to produce better performance (higher frame rate/sec, more continous audio), I may have a *HOT* project today and tomorrow (9/14 & 9/15) (BTW: is there any mbone activity going on during this time?) I need the answer -NOW-, so any inputs are greatly appreciated. Thanks. --Wo Chang From rem-conf-request@es.net Tue Sep 14 10:29:46 1993 Received: from bnl.gov by osi-east.es.net via ESnet SMTP service id <09349-0@osi-east.es.net>; Tue, 14 Sep 1993 07:22:05 +0000 Received: by bnl.gov (5.57/Ultrix3.0-C) id AA00774; Tue, 14 Sep 93 10:21:40 -0400 Received: by maeva.ccd.bnl.gov.ccd.bnl.gov (5.0/SMI-SVR4) id AA11843; Tue, 14 Sep 93 10:21:35 EDT Date: Tue, 14 Sep 93 10:21:35 EDT From: gc@maeva.ccd.bnl.gov (Graham Campbell) Message-Id: <9309141421.AA11843@maeva.ccd.bnl.gov.ccd.bnl.gov> To: rem-conf@es.net, mbone@isi.edu, chang@muon.nist.gov Subject: Re: workstation for mbone Cc: wchang@nist.gov X-Sun-Charset: US-ASCII Content-Length: 816 > 1) Which workstation [ready to use for mbone multicast -- no need to > modify the kernel; its system configuration and network environment > (FDDI or Ethernet)] will produce the best performance (higher > frame rate/sec, more continous audio) for both transmitting and > receiving audio/video over the mbone? I cannot answer the general question, but I can rule out some systems according to your criteria. Suns under SunOS4.x require kernel mods for mulitcast support. Suns under Solaris 2.2 require a mod to support encapsulated tunnels. SGI systems under IRIX Release 4.0.5F need (but do not require) an upgrade of the ethernet driver to the H system level to avoid occasionally putting badly formed packets on the Ethernet. I think this reduces your options somewhat. Graham From rem-conf-request@es.net Tue Sep 14 13:50:03 1993 Received: from norman.nwnet.net by osi-east.es.net via ESnet SMTP service id <10026-0@osi-east.es.net>; Tue, 14 Sep 1993 08:29:04 +0000 Received: by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA02922; Tue, 14 Sep 93 08:28:55 -0700 Date: Tue, 14 Sep 1993 08:25:31 -0700 (PDT) From: Allen Robel Subject: Re: Video over slip To: Scott W Brim Cc: Ron Frederick , rem-conf@es.net In-Reply-To: <199309140329.AA15963@postoffice.mail.cornell.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 13 Sep 1993, Scott W Brim wrote: > interpolation of visual information. Psychologically and physiologically, > what aspects of video can be absent, or erroneous, and still have the video > be tolerable to the viewer? Which of these aspects can be dropped with the > least degradation of the viewer's subjective experience? Which ones offer > the greatest relief in processing overhead and bandwidth requirement? > Beats me. I don't know the literature on this, since I haven't had time to For a start on the literature, you might want to FTP the bibliography that I maintain on ftp.nwnet.net /user-docs/cell-relay/bib/* Its mostly an ATM bibliography, but I've included references like the one below. Look at the 1st entry in the bibliography for a description of the format of the entries. regards, Allen Robel Internet: allen@nwnet.net Network Engineer voice: (206)562-3000 NorthWestNet FAX: (206)562-4822 Objective Quality Assessment of Digitally Transmitted Video: Wolf, Stephen.; Pinson, Margaret H.; Voran, Stephen D.; Webster, Arthur A.: U.S. Department of Commerce, NTIA/ITN.N3, 325 Broadway, Boulder, CO 80303: IEEE Pacific Rim Conference on Communications, Computers and Signal Processing: May 9th, 10th: 1991: 477-482: 2 volumes: : IEEE Catalog order No. 91CH2954-6, Library of Congress Catalog Card No. 90-655140 ISBN 0-87942-638-1 (Softbound) ISBN 0-87942-639-x (Casebound) ISBN 0-87942-640-3 (Microfiche) No order information given, try IEEE Service Center Publications Sales Department 445 Hoes Lane PO Box 1331 Piscataway, NJ 08855-1331: This paper describes a segment of the video quality measurement work currently being performed at the Institute for Telecommunication Sciences, National Telecommunications and Information Administration. A newly developed automated method and laboratory system for performing objective video quality measurements is presented. The method is based on extraction and classification of features from sampled input and output video. The extracted features quantify many of the distortions present in modern digital compression and transmission systems. These distortions include video compression artifacts resulting from spatial compression (blocking, edge blurring/smearing, etc) and temporal compression (image persistence, jerky motion, etc). Since the quality of the motion and still portions of a video scene can differ dramatically, an algorithm that segments each video frame into motion and still parts has been developed. Several of the features are currently being considered for inclusion into the draft standard of Analog Interface Performance Specifications for Digital Video Teleconferencing/Video Telephony service by the American National Standards Institute (ANSI) Accredited Standards Committee T1, Working Group T1Q1.5, Video Teleconferencing/Video Telephony Sub-working Group.; keywords=; video quality assessment. ; video; videoconference; videoconferencing; video teleconferencing (VTC); ANSI T1Q1.5 draft standard Analog Interface Performance Specifications for Digital Video Teleconferencing/Video Telephony Service; video codec; spatial blurring; temporal blurring; quantization blocking; edge busyness; image persistence; color distortion; Laplacian, Sobel filters; motion-still segmentation algorithm; compressed video; video compression; video signal distortion; measurement methods: From rem-conf-request@es.net Tue Sep 14 18:30:15 1993 Received: from alpha.Xerox.COM by osi-east.es.net via ESnet SMTP service id <14387-0@osi-east.es.net>; Tue, 14 Sep 1993 15:18:50 +0000 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12024(1)>; Tue, 14 Sep 1993 15:18:30 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 14 Sep 1993 15:18:25 -0700 To: rem-conf@es.net, mbone@isi.edu Subject: Xerox PARC Forum Sept. 16 -- Boggs & Metcalfe, History of Ethernet Date: Tue, 14 Sep 1993 15:18:13 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Sep14.151825pdt.12171@skylark.parc.xerox.com> We *may* get permission from Dave Boggs and Bob Metcalfe to transmit the following PARC Forum talk over the MBone, but we won't know until just before the talk begins. If we do get the go-ahead, the talk will be at 4:00 PM Pacific Daylight Time on Thursday, Sep 16. The audio and video sessions are advertised in 'sd' with the following parameters: Xerox PARC Forum - Audio 224.2.199.198 port 49373 id 0 ttl 159 Xerox PARC Forum - Video 224.2.199.199 port 49375 id 0 ttl 95 ------------------------- PARC Forum Thursday, September 16, 1993 PARC Auditorium, 4:00 P.M. Ethernet 20th Birthday -- Early History of the Ethernet Bob Metcalfe, Publisher, Infoworld Dave Boggs, DEC Western Research Laboratory May 22, 1973 was the birthday of the Ethernet. On that date, Bob Metcalfe used the word Ethernet in a memo to describe a project previously known as the Alto Aloha net. And Ethernet has been a major part of local area networks ever since. At this Forum, the inventors of Ethernet will look back at the situation and events of 20 years ago. ---What were the initial goals? How did they change over time? ---What were Ethernet's main competitors in 1973? Why didn't they succeed? ---Why was the initial data transfer rate fixed at exactly 2.94 Mbit/second? How did it eventually get to 10 Mbps? ---How did Intel and DEC get involved? How did Ethernet become a standard? Were there any compromises? ---A glimpse towards the future of Ethernet. Host: Giuliana Lavendel/PARC Information Center ------------------------- This Forum is OPEN to the public. For more information contact Giuliana Lavendel or Kathy Jarvis at (415) 812-4042 or KJarvis@PARC.xerox.com Refreshments will be served at 3:45 P.M. for Forum Attendees only. The PARC Auditorium is located at 3333 Coyote Hill Rd. in Palo Alto. PARC is in the Stanford Research Park, between Page Mill Road (west of Foothill Expressway) and Hillview Avenue. The easiest route is to take Page Mill Road and turn onto Coyote Hill Road. As you drive up Coyote Hill past the horse pastures, PARC is the building on the left after you crest the hill. Park in the large lot, and enter the auditorium at the upper level of the building. (The auditorium entrance is located down the stairs and to the left of the main doors.) From rem-conf-request@es.net Wed Sep 15 01:00:49 1993 Received: from taurus.cs.nps.navy.mil by osi-east.es.net via ESnet SMTP service id <16699-0@osi-east.es.net>; Tue, 14 Sep 1993 21:53:23 +0000 Received: by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA26185; Tue, 14 Sep 93 21:54:18 PDT Date: Tue, 14 Sep 93 21:54:18 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9309150454.AA26185@taurus.cs.nps.navy.mil> To: rem-conf@es.net Subject: SciVis Workshop on the MBONE (long) We succeeded in getting USGS late this afternoon and so there will be an mbone Scientific Visualization workshop Wednesday and Thursday. Based on all positive and no negative responses to our previous announcement, we have set TTL to world. Bandwidth will be limited to 125 KBps (default value). If this is a problem please contact me as well as Mike McCann (mccann@nps.navy.mil) and we will scale back accordingly. We don't want to cause congestion problems, particularly with NASA Select on the net. Thanks also to Van Jacobsen for helping us experiment with vat in the setup for the conference. regards, Don Donald P. Brutzman LCDR USN work (408) 656-2149 Code OR/Br Naval Postgraduate School [Glasgow 204] fax (408) 656-2595 Monterey California 93943-5000 USA home (408) 372-0190 ====================== Scientific Visualization Workshop Coordinator: Carol Lawson CLAWSON@ISDMNL.WR.USGS.GOV ********************************************************************** Menlo Park Scientific Visualization Program Wednesday 9/15/93 and Thursday 9/16/93 WEDNESDAY SEPTEMBER 15, 1993 7:45 am Registration Conference Facility A Program (Speakers) 8:45 am Introductory Remarks Workshop Coordinator Assistant Director for Information Systems USGS Scientific Visualization Subcommittee Chairman 9:00 am Keynote Address Dr. Gary Greene, USGS, Pacific Marine Geology The value of scientific visualization from a scientists perspective. 9:45 am Ralph Cheng, USGS, Water Resources Division - Branch of Regional Research, Menlo Park, CA Talk: Interactive computer graphics visualization programs showing the hydrodynamic properties of the San Francisco Bay waters. NOTE: This talk will be repeated on Thursday at 11:15am. 10:15 am Don Brutzman, Naval Postgraduate School, Monterey, CA Talk: Terrain visualization and sensor interactions in an underwater virtual world provided for an autonomous underwater vehicle. Talk: Use of a multicast backbone (MBONE) Internet link to broadcast the Scientific Visualization Workshop. NOTE: These talks will be repeated on Thursday at 1:15pm. 10:45 am Break 11:00 am William Acevedo, USGS, National Mapping Division, Menlo Park, CA Talk: Computational geometry and stereoscopic visualization techniques used with earthquake hypocenter data to create a visual model of the volcanic structure underlying the island of Hawaii. 11:30 am Lunch Break 1:30 pm Alan Mikuni, USGS, National Mapping Division, Menlo Park, CA Talk: The digital orthophotoquad program: production, procedures, history, technical overview and potential applications. NOTE: A demonstration of these products will take place at 2:30pm in the GIS Laboratory in Room 3188A. 2:00 pm Kevin Hussey, Jet Propulsion Laboratory, Pasadena, CA Talk: Capabilities of Surveyor, an interactive software package used to develop 2-D and 3-D animated explorations of large terrain databases. 2:30 pm Break 2:45 pm Alex Pang, University of California at Santa Cruz, Santa Cruz, CA Talk: A rendering technique developed at UCSC that uses a metaphorical abstraction of virtual cans of spray paint for rendering data sets in various ways. NOTE: This talk will be repeated on Thursday at 1:45pm. 3:15 pm Bob Mark, USGS, Western Regional Geology, Menlo Park, CA Talk: A complex Monte Carlo simulation model generated debris-flow hazard map of the Honolulu District of Oahu, Hawaii Digital Orthophotoquad Program (Room 3188A and 3188B) 2:30 pm Liz Wegenka, USGS, National Mapping Division, Menlo Park, CA Demonstration: A demonstration of the new topographic map production and revision process using digital line graph data (DLGs) and digital orthophotoquads (DOQs ) of 7.5' quadrangles. POSTER SESSIONS -- WEDNESDAY SEPTEMBER 15, 1993 THURSDAY SEPTEMBER 16, 1993 FRIDAY SEPTEMBER 17, 1993 Conference Facility B Program (Poster Sessions and Demonstrations) BOOTH 1 Kevin Hussey and Dan Stanfill Organization: Jet Propulsion Laboratory (JPL) Demonstration: A demonstration of the capabilities of Surveyor, an interactive software package used to develop 2-D and 3-D animations. Surveyor can be used to explore extremely large terrain databases and produce animations from these databases, and has been used in collaborative projects undertaken between USGS and JPL. BOOTH 2 Ralph Cheng and Jon Burau Organization: USGS, Water Resources Division Demonstration: A series of interactive computer graphics visualization programs showing the hydrodynamic properties of the San Francisco Bay waters. BOOTH 3 Sam Arriola Organization: USGS, Information Systems Division Demonstration: An interactive tutorial of Surveyor, an animation software package, and animations of planetary studies. BOOTH 4 Harry Jenter (staffed by ISD) Organization: USGS, Water Resources Division (Reston) Poster Session: Posters and a videotaped visualization model of circulation and effluent transport in Massachusetts Bay. BOOTH 5 William Acevedo and Fred Klein Organization: USGS, National Mapping Division and Geologic Division (Seismology) Demonstration: An interactive demonstration of computational geometry and stereoscopic visualization techniques used with earthquake hypocenter data to create a computer generated model of the volcanic structure underlying the island of Hawaii. BOOTH 6 Mike Doukas Organization: USGS, Geologic Division (Alaska Volcano Observatory) Demonstration: Videotaped studies of ten years of volcanic eruptions in Alaska including a night view of the eruption of Veniaminof and day views of Akutan, West Dahl, Augustine, Redoubt, and Spur eruptions. BOOTH 7a Fred Klein and Steve Walter Organization: USGS, Geologic Division (Seismology) Demonstration: Interact with earthquakes! Interactive use of Amiga computer 2-D and 3-D animations to view current seismicity in 18 regions in California, fly along the face of the Loma Prieta aftershock zone, fly over the trace of the Hayward fault, and test you knowledge of California's active faults. BOOTH 7b Barbara Bogaert and Allan Lindh Organization: USGS, Geologic Division (Seismology) Demonstration: Earthquakes as they happen: Near real-time epicenter locations via nationwide radio pagers. Display of plots and text for California, national, and worldwide data. BOOTH 8 Jim Borchers Organization: USGS, Water Resource Division Poster Session and Demonstration: What's under El Capitan? Borehole geophysical instruments and televiewing tools allow rocks, fractures, mineral veins, and faults to be mapped and studied to depths of more than 1,000 feet beneath the surface in Yosemite National Park. BOOTH 9 Tau Rho Alpha Organization: USGS, Geologic Division (Technical Reports) Poster Session and Demonstration:Three dimensional animations of the evolution of landforms. BOOTH 10 Dan Mosier Organization: USGS, Geologic Division (Resource Analysis) Demonstration: Two-dimensional animated models of the formation of various ore deposit types that occur around the world. BOOTH 11 Bob Mark and Steve Ellen Organization: USGS, Geologic Division (Regional Geology and Geologic Risk Assessment) Poster Session and Demonstration: A complex Monte Carlo simulation model generated debris-flow hazard map of the Honolulu District of Oahu, Hawaii, with a Quick time animated explanation of the model behind the map. BOOTH 12 George Gryc and Fran Mills Organization: USGS, Geologic Division (International Geology) Poster Session: Description of multiple phases of the cooperative international Circumpacific Map Project which is designed to show the relationship of energy and mineral resources to major geologic features of the Pacific basin and surrounding continental areas. BOOTH 13 Richard Pike Organization: USGS, Geologic Division (Regional Geology) Poster Session: The visualization of synoptic topography of the United States, Italy, Sweden, and the Mediterranean by digital shaded relief. BOOTH 14 Bob Hall, Jere Swanson, and Norm Maher Organizations: Environmental Protection Agency, USGS-National Mapping Division, and USGS Geologic Division (Pacific Marine Geology) Poster Session: Three-dimensional shaded relief bathymetric imagery of the coastal area of central California created by offsetting the red and blue channels. BOOTH 15 Dan Snyder Organization: USGS, Water Resources Division (Portland, Oregon) Poster Session: Posters showing a GIS interface with a particle tracker for a ground-water flow model developed to identify the location of recharge areas, locate contaminant sources, map the down-gradient parts of the flow system, and map the age of the ground water throughout the ground-water flow system. BOOTH 16 Brian Reece, Rita Carman, and Tim Liebermann Organization: USGS, Water Resources Division (Carson City, NV) Demonstration and Poster Session: Demonstration of a preliminary multi-agency network for interactive display and query of real-time data. BOOTH 17a Clint Steele, Carolyn Degnan, and Michael Hamer Organization: USGS, Geologic Division (Marine Geology) Poster Session: Monterey Bay National Marine Sanctuary bathymetric visualization poster session. BOOTH 17b Florence Wong Organization: USGS, Geologic Division (Marine Geology) Poster Session: A poster session of multi-scale maps of the Pacific continental margin and Exclusive Economic Zone (EEZ). BOOTH 18a Dennis McMacken Organization: USGS, Information Systems Division (Flagstaff, AZ) Poster Session: Demonstrations of the scientific visualization applications developed at Flagstaff showing past, present, and future capabilities using multi-media, CD-ROM, and video techniques. BOOTH 18b Alex Acosta Organization: USGS, Information Systems Division (Flagstaff, AZ) Demonstration: A demonstration of the Macintosh digital mapping system computerized mapping process used to generate color separates for thematic maps. THURSDAY SEPTEMBER 16, 1993 Conference Facility A Program (Speakers) 9:30 am Introductory Remarks 9:45 am Jim Borchers, USGS, Water Resources Division (Sacramento, CA) Talk: What's under El Capitan? Borehole geophysical instruments and televiewing tools allow rocks to be studied in situ below Yosemite National Park. 10:15 am Dan Snyder, USGS, Water Resources Division (Portland) Talk: A GIS interface with a particle tracker for a ground water flow model. 10:45 am Break 11:15 am Ralph Cheng, USGS, Water Resources Division - Branch of Regional Research, Menlo Park, CA Talk: Interactive computer graphics visualization programs showing the hydrodynamic properties of the San Francisco Bay waters. 11:45 am Lunch Break 1:15 pm Don Brutzman, Naval Postgraduate School, Monterey, CA Talk: Terrain visualization and sensor interactions in an underwater virtual world provided for an autonomous underwater vehicle. Talk: Use of a multicast backbone (MBONE) Internet link to broadcast the Scientific Visualization Workshop. 1:45P pm Alex Pang, University of California at Santa Cruz, Santa Cruz, CA Talk: A rendering technique developed at UCSC that uses a metaphorical abstraction of virtual cans of spray paint for rendering data sets in various ways. 2:15 pm Kevin Hussey, Jet Propulsion Laboratory, Pasadena, CA Talk: Capabilities of Surveyor, an interactive software package used to develop 2-D and 3-D animated explorations of large terrain databases. Digital Orthophotoquad Program (Room 3188A and 3188B): 2:30 pm Liz Wegenka, USGS, National Mapping Division, Menlo Park, CA Demonstration: A demonstration of the new topographic map production and revision process using digital line graph data (DLGs) and digital orthophotoquads (DOQs) of 7.5' quadrangles. ============================================================================ README.MBMG: Monterey Bay Modeling Group anonymous ftp archive taurus.cs.nps.navy.mil 131.120.1.13 anonymous ftp to taurus.cs.nps.navy.mil, then cd pub/mbmg set file type binary prior to any transfer You may also upload files, just let me know what you have sent This archive is used as a holding location for postscript files and other information used to support the Monterey Bay Modeling Group, especially for technical broadcasts over the MBONE (Multicast backBONE). ============================================================================ Files for USGS Scientific Visualization Workshop 15-16 SEP 93: workshop_program who what when calren.intro California Research & Education Network info calren.details aaai92ws.slides.ps.Z postscript file, Don Brutzman's talk on underwater virtual world for an autonomous underwater vehicle usgs93ws.ps.Z postscript file, Don Brutzman's talk on MBMG/MBONE various *.rgb.Z files: compressed MBONE images, render on SGI workstation by typing 'ipaste mbone_image.rgb' sorry there aren't more! this is our first time hosting an mbone event. ============================================================================ [note: uncompress files under Unix using 'uncompress file.name.Z'] [note: NPS AUV papers can be found in directory ~ftp/pub/auv] regards, Don Donald P. Brutzman LCDR USN brutzman@nps.navy.mil work (408) 656-2149 Code OR/Br Naval Postgraduate School [Glasgow 204] fax (408) 656-2595 Monterey California 93943-5000 USA home (408) 372-0190 From rem-conf-request@es.net Wed Sep 15 10:59:51 1993 Received: from csi2.ns.nts.uci.edu by osi-east.es.net via ESnet SMTP service id <19436-0@osi-east.es.net>; Wed, 15 Sep 1993 07:59:17 +0000 Received: from red-october.nts.uci.edu by csi2.ns.nts.uci.edu with SMTP id AA22653 (5.65b/IDA-1.4.3 for rem-conf@es.net); Wed, 15 Sep 93 07:59:00 -0700 Message-Id: <9309151459.AA22653@csi2.ns.nts.uci.edu> Date: Wed, 15 Sep 1993 08:02:22 -0800 To: rem-conf@es.net From: kchong@uci.edu (Keith Chong) X-Sender: kchong@mothra.nts.uci.edu Subject: (MBONE):Emerging Computer Technology and Managed Care The Long Beach Regional Medical Education Center is presenting a conference entitled "Emerging Computer Technology and Managed Care" on Sept 21 and 22 from 8:30 to 4:30 PDT. We at UC Irvine are working with them to set up an mbone link and transmit the conference to the rest of the mbone. We are planning on using 128kbps and a TTL set to the world. If anyone sees this as a problem please let us know. Thanks much Keith Chong UCI-Electronic Communication Services Kchong@uci.edu (714)856-8394 ============================================================================= Day 1 ============================================================================= EMERGING COMPUTER TECHNOLOGY AND MANAGED CARE Tuesday, September 21, 1993 Long Beach RMBC Auditorium LBRMEC Staff Registration 8:30 - 8:45 a.m. and Coffee Dr. Moravec Introductions 8:45 - 9:00 a.m. Dr. Lussier Tom Garthwaite, M.D. The Future of VA Computing 9:00 - 9:30 a.m. Chair of IRAC, COS Milwaukee VAMC Jim Laub, Pharm.D. Designing a Clinical 9:30 - 10:30 a.m. Clinical Pharmacist Graphical User Interface Phoenix VAMC, CARG Break %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 10:30 - 10:40 a.m. Tom Garthwaite, M.D. Q & A 10:40 - 11:10 a.m. Jim Laub, Pharm.D. Locally Developed Clinical Software 11:10 - 12:20 p.m. Lunch %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 12:20 - 1:30 p.m. Steven Fehlauer, M.D. Wireless, Pen-Based 1:30 - 2:30 p.m. SLC GRECC Clinical Workstations Break %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 2:30 - 2:40 p.m. Tom Garthwaite, M.D. Panel Discussion 2:40 - 3:40 p.m. Jim Laub, Pharm.D. Steven Fehlauer, M.D. Walt Henry, M.D. THIS IS A CHANGE | V #Alan Robbins, M.D. 3:40 - 4:30 p.m. # Sepulveda VAMC # Chief of Staff Adjourn %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 4:30 p.m. ============================================================================= Day 2 ============================================================================= EMERGING COMPUTER TECHNOLOGY AND MANAGED CARE Wednesday, September 22, 1993 Long Beach RMEC Auditorium William F. Bria, M.D. Person Side Computing 9:00 - 10:00 a.m. Director of Clinical The Evolution of the Information Systems Medical Information Univ of Michigan Instrument Medical Center Break %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 10:00 - 10:10 a.m. Douglas McConnell, M.D. The Use of a Graphical User 10:10 - 11:10 a.m. Chief of Surgery Interface in an Intensive LB Memorial Hospital Care Unit Break 11:10 - 11:20 a.m. THIS IS A CHANGE | V >Poster Session 11:20 - 12:30 p.m. Lunch 12:30 - 1:30 p.m. R. Scott Evans, Ph.D. The Antibiotic Assistant: 1:30 - 2:30 p.m. Director of Research An Expert System Dept. of Epidemiology LDS Hospital Break 2:30 - 2:40 p.m. James E. Dewey, Ph.D. Quality Management and 2:40 - 3:40 p.m. President Outcomes Research In Response Technologies Healthcare Adjourn 3:40 p.m. From rem-conf-request@es.net Thu Sep 16 10:43:52 1993 Received: from thdsun.EPM.ORNL.GOV by osi-east.es.net via ESnet SMTP service id <29297-0@osi-east.es.net>; Thu, 16 Sep 1993 07:32:55 +0000 Received: by thdsun.EPM.ORNL.GOV (4.1/1.34) id AA13399; Thu, 16 Sep 93 10:32:52 EDT Date: Thu, 16 Sep 93 10:32:52 EDT From: dunigan@thdsun.EPM.ORNL.GOV (Tom Dunigan 576-2522) Message-Id: <9309161432.AA13399@thdsun.EPM.ORNL.GOV> To: rem-conf@es.net Subject: vat and watchdog resets on Suns Some of our Sparc2's have crashed with "watchdog resets" when audio from the net into vat starts up. Anyone else seen this or know of a fix. The Sparc 2's are running the multicast 4.1.2 kernel. thanks tom From rem-conf-request@es.net Thu Sep 16 11:47:24 1993 Received: from ietf.cnri.reston.va.us by osi-east.es.net via ESnet SMTP service id <29943-0@osi-east.es.net>; Thu, 16 Sep 1993 08:37:08 +0000 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06372; 16 Sep 93 11:08 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: rem-conf@es.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ietf-avt-rtp-03.txt, .ps Date: Thu, 16 Sep 93 11:08:40 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9309161108.aa06372@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP: A Transport Protocol for Real-Time Applications Author(s) : H. Schulzrinne, S. Casner Filename : draft-ietf-avt-rtp-03.txt, .ps Pages : 36 This memorandum describes a protocol called RTP suitable for the end-to-end network transport of real-time data, such as audio, video or simulation data for both multicast and unicast transport services. The data transport is augmented by a control protocol (RTCP) designed to provide minimal control and identification functionality particularly in multicast networks. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and bridges. Within multicast associations, sites can direct control messages to individual sites. The protocol does not address resource reservation and does not guarantee quality-of-service for real-time services. This specification is a product of the Audio-Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-avt-rtp-03.txt". Or "get draft-ietf-avt-rtp-03.ps". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-avt-rtp-03.txt". Or "SEND draft-ietf-avt-rtp-03.ps". For questions, please mail to internet-drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ietf-avt-rtp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart-- From rem-conf-request@es.net Thu Sep 16 13:22:21 1993 Received: from nic.cic.net by osi-east.es.net via ESnet SMTP service id <01308-0@osi-east.es.net>; Thu, 16 Sep 1993 10:21:47 +0000 Received: by nic.cic.net (4.1/SMI-4.1) id AA25390; Thu, 16 Sep 93 13:21:40 EDT Message-Id: <9309161721.AA25390@nic.cic.net> To: dunigan@thdsun.epm.ornl.gov (Tom Dunigan 576-2522) Cc: rem-conf@es.net Subject: Re: vat and watchdog resets on Suns In-Reply-To: Your message of "Thu, 16 Sep 93 10:32:52 EDT." <9309161432.AA13399@thdsun.EPM.ORNL.GOV> Date: Thu, 16 Sep 93 13:21:39 -0400 From: Thomas Easterday >Some of our Sparc2's have crashed with "watchdog resets" when >audio from the net into vat starts up. Anyone else seen this >or know of a fix. The Sparc 2's are running the multicast 4.1.2 kernel. I have seen this several times on my IPX running 4.1.2 also. The last time it happened was when the time annoucement stuff was just starting up. I saw a complaint about packets being too large or something like that just before the crash. It hasn't happened for a couple weeks now... Tom From rem-conf-request@es.net Thu Sep 16 14:29:54 1993 Received: from LION.BBN.COM by osi-east.es.net via ESnet SMTP service id <02208-0@osi-east.es.net>; Thu, 16 Sep 1993 11:29:10 +0000 Received: by lion.bbn.com (AA00859); Thu, 16 Sep 93 14:29:02 EDT Date: Thu, 16 Sep 93 14:29:02 EDT From: Bob Clements Message-Id: <9309161829.AA00859@lion.bbn.com> To: tom@cic.net Cc: dunigan@thdsun.epm.ornl.gov, rem-conf@es.net In-Reply-To: Thomas Easterday's message of Thu, 16 Sep 93 13:21:39 -0400 <9309161721.AA25390@nic.cic.net> Subject: vat and watchdog resets on Suns From: Thomas Easterday [Re: watchdog crashes on Suns] I have seen this several times on my IPX running 4.1.2 also. The last time it happened was when the time annoucement stuff was just starting up. I saw a complaint about packets being too large or something like that just before the crash. It hasn't happened for a couple weeks now... Tom Hmm. When I was sending my imitation-WWV-formatted time stuff, I was using larger packets to try to keep the packets-per-second down. I had an audio payload of 400 bytes per packet rather than 160. Not exactly a huge packet, but larger than the usual VAT packet. I hope this wasn't a problem. It didn't cause us any trouble here (4.1.3 on IPCs and Sparc-10s.) Also, I didn't do it when the time announcement stuff was "just starting", but jumped on the bandwagon a couple days later. Re-tests available on request, as soon as I get my program glued back together from its latest surgery. I just mention it because of the "packets too large" comment from Tom. Bob Clements, K1BC, clements@bbn.com From rem-conf-request@es.net Thu Sep 16 15:23:58 1993 Received: from faui45.informatik.uni-erlangen.de by osi-east.es.net via ESnet SMTP service id <02937-0@osi-east.es.net>; Thu, 16 Sep 1993 12:15:36 +0000 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA19713 (5.65c-5/7.3v-FAU); Thu, 16 Sep 1993 21:15:13 +0200 Received: from faui45r.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA26345 (5.65c-5/7.3m-FAU); Thu, 16 Sep 1993 21:15:10 +0200 From: Toerless Eckert Message-Id: <199309161915.AA26345@faui43.informatik.uni-erlangen.de> Subject: Idle timeout for mbone applications To: mbone@isi.edu, rem-conf@es.net Date: Thu, 16 Sep 93 21:14:32 MET DST Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.3 PL11] Hello I would like to know if those of you who develop the applications that run on mbone have thought about introducing an "idle timeout" for the user connections to multicast channels. I think it is quite common for people on mbone to have some vat, nv, ivs, whatever windows up and running, even if there is personally no one listening or watching. Now with the upcoming introduction of real multicast routing in mbone (pruning) this actually makes a difference in load on the network. If we all would be brave and say "quit" to those applications, whenever we leave the workstation and restart those applications, whenever we come back to listen and watch, no addition to the existing software would be required. I think it is unrealistic to hope for this usage of the programs, though. Thus, i think, all applications on mbone should have a provision to check if there is really someone watching or listening and to leave the multicast channels automatically, if they see that there is no actual local recipient. The application should continue to run, and if it detects that there is again the user active on the host, the application should reconnect to the multicast groups. The most easy scheme (on suns) would probably be to track /dev/kbd, and if it's idle for more than 10 minutes deactivate the session, and reactivate it again if the keyboard becomes active again. Of course this would not fit all user needs, so it would of course be more appropriate to have some kind of extensible scheme that would allow for modifications by the local user. Probably the most geneal approach would be to define a multicast group with a host-local ttl, where all applications bind to, and where one activity detection application would then broadcast activation and deactivation events onto. This could be a simple application just sending out defined packets of the kind "user has beomce inactive" and "user has become active". As that application could be available in source it would allow the users to invent their own schemes on how to detect their activity, and then after some time of testing this out there could probably be a version implementing several mechanisms of activity detection, that one can chose from. (of course even this simple thing could be made endlessly complex, but the basic idea is to reduce the traffic on mbone caused by all of us lazy users, and have it accepted by all of the users, because it's easy and i can tweak it for my environment). Best regards -- Toerless Eckert From rem-conf-request@es.net Thu Sep 16 15:26:52 1993 Received: from alpha.Xerox.COM by osi-east.es.net via ESnet SMTP service id <02971-0@osi-east.es.net>; Thu, 16 Sep 1993 12:20:35 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <11658(1)>; Thu, 16 Sep 1993 12:20:16 PDT Received: by ecco.parc.xerox.com id <16136>; Thu, 16 Sep 1993 12:20:10 -0700 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.ecco.parc.xerox.com.sun4.41 via MS.5.6.ecco.parc.xerox.com.sun4_41; Thu, 16 Sep 1993 12:20:05 -0700 (PDT) Message-ID: Date: Thu, 16 Sep 1993 12:20:05 PDT Sender: Ron Frederick From: Ron Frederick To: David Walker Subject: Re: Video over slip CC: rem-conf@es.net In-Reply-To: <199309132347.AA02041@mothra.nts.uci.edu> References: <199309132347.AA02041@mothra.nts.uci.edu> David Walker writes: > I've gotten the comment (from a high-level campus administrator) that > it would be nice to have a lower-quality mode that achieves a higher > frame rate. It seems to me that this could be a reasonable compromise > for many applications of nv, given that many of the cameras are not > very high quality, anyway. If all one wants is the general sense of a > person's face while that person is talking, a little graininess would be > fine. Yes - I was hoping to be able to do this by simply using a higher thresholding factor with my current nv compression scheme. I planned to make the threshold user-settable, as kind of a "quality" slider, so you could trade off quality for either lower bandwidth or higher frame rate. Unfortunately, the scheme I'm using right now as a pretty sharp knee right around the threshold I'm using. There wasn't enough range there to really get the gradual drop in quality that I wanted. So, I stuck with only two thresholds (none, for background data, and a hardcoded one I hand-tuned for moving data). I agree that nv's current compression sacrifices frame rate for quality a bit more than I'd like sometimes, and I'm still looking for a mechanism by which I could get somewhat lower quality but better compression, and thus a better frame rate on cards that can handle it. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Thu Sep 16 17:17:15 1993 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <04313-0@osi-east.es.net>; Thu, 16 Sep 1993 14:16:37 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Thu, 16 Sep 1993 14:16:34 -0700 Posted-Date: Thu 16 Sep 93 14:15:53-PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Thu, 16 Sep 93 14:15:54 PDT Date: Thu 16 Sep 93 14:15:53-PDT From: Stephen Casner Subject: Last Call in AVT WG for RTP spec To: rem-conf@es.net Message-Id: <748214153.0.CASNER@XFR.ISI.EDU> Mail-System-Version: To the Audio/Video Transport WG and other interested parties: Version 3 of the Real-Time Transport Protocol (RTP) specification Internet Draft draft-ietf-avt-rtp-03.txt, .ps is now available from the I-D repositories. ** This is the last call for comments within the working group before ** the draft is submitted to the IESG with a request for publication ** as an RFC. Comments are due within one week, so that the draft can ** be submitted next Friday, September 24. Based on the discussion in the working group teleconference on August 17, proposed standard status will be requested for this protocol. Updates of the companion drafts on Encodings and Profile will be released shortly with small changes to incorporate the comments returned on the July 30 versions of those drafts. -- Steve Casner ------- From rem-conf-request@es.net Thu Sep 16 18:43:49 1993 Received: from timbuk.cray.com by osi-east.es.net via ESnet SMTP service id <05448-0@osi-east.es.net>; Thu, 16 Sep 1993 15:35:46 +0000 Received: from frenzy.cray.com by cray.com (4.1/CRI-MX 2.19) id AA02113; Thu, 16 Sep 93 17:35:43 CDT Received: by frenzy.cray.com id AA03522; 4.1/CRI-5.6; Thu, 16 Sep 93 17:36:50 CDT Date: Thu, 16 Sep 93 17:36:50 CDT From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9309162236.AA03522@frenzy.cray.com> To: rem-conf@es.net Subject: mrouted questions Hi. I'm trying to get an mrouted tunnel set up from a Sun to an SGI machine. The Sun is running 4.1.3 with the multicast changes from the net (and it works just fine), the SGI is IRIX Release 4.0.5F System V. I'm using the multicast code that came with the SGI machine. I have a srcrt tunnel set up in the mrouted.conf between the two machines (since that is all the SGI machine supports). Both machines are sending an receiving IGMP information (seen by running mrouted in debug mode). An sd running on the SGI is not picking up anything. I created a new vat session on the SGI machine, and it was seen on the Sun. I opened the session on both, and the Sun saw both participants, but the SGI only saw itself. So it appears that multicast traffic is going through the tunnel from the SGI to the Sun ok, but the reverse direction is not working. In a netstat -s, the SGI has the "packets not forwardable" counter going up and up, so for some reason it is getting the source routed traffic, but not recognizing the multicast addresses, and trying instead to forward them??? (When I turn off the other end of the tunnel, the counter stands still.) Any help or insights would be greatly appreciated. -David Borman, dab@cray.com From rem-conf-request@es.net Thu Sep 16 20:48:57 1993 Received: from desire.wright.edu by osi-east.es.net via ESnet SMTP service id <06911-0@osi-east.es.net>; Thu, 16 Sep 1993 17:42:32 +0000 Received: from DESIRE.WRIGHT.EDU by DESIRE.WRIGHT.EDU (PMDF V4.2-10 #2485) id <01H312IYZU8W003KMW@DESIRE.WRIGHT.EDU>; Thu, 16 Sep 1993 20:42:26 EST Date: Thu, 16 Sep 1993 20:42:26 -0500 (EST) From: Ed Jones Subject: ip-multicast for DEC OSF/1 To: rem-conf@es.net Message-id: <01H312IZ03W2003KMW@DESIRE.WRIGHT.EDU> X-VMS-To: IN%"rem-conf@es.net" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Someone told me that vat,sd and nv have been ported to Alpha. I found these but I can't find the kernal mods to set up ip-multicast. Can anyone tell me where I can find these? Thanks very much. Ed Jones **************************************************************************** * Ed Jones | ejones@desire.wright.edu * * Department of Psychology | ejones@sdl.psych.wright.edu * * Signal Detection Lab | ejones@wsu (Bitnet) * * Wright State University | * **************************************************************************** From rem-conf-request@es.net Thu Sep 16 21:44:00 1993 Received: from inet-gw-2.pa.dec.com by osi-east.es.net via ESnet SMTP service id <07513-0@osi-east.es.net>; Thu, 16 Sep 1993 18:38:06 +0000 Received: by inet-gw-2.pa.dec.com; id AA25918; Thu, 16 Sep 93 18:38:04 -0700 Received: by oreo.pa.dec.com; id AA05960; Thu, 16 Sep 93 18:37:59 -0700 Message-Id: <9309170137.AA05960@oreo.pa.dec.com> To: Ron Frederick Cc: David Walker , rem-conf@es.net, berc@Pa.dec.com Subject: Re: Video over slip In-Reply-To: Message of Thu, 16 Sep 1993 12:20:05 PDT from Ron Frederick Date: Thu, 16 Sep 93 18:37:58 -0700 From: berc@src.dec.com X-Mts: smtp We put a quality slider in our JPEG-based conferencing software, and have played around with it quite a bit. It doesn't get much use when conferencing around the building, but it's nice to adjust the quality when getting a source from a distance. The video servers support 16 quality levels which can be different on each server, though they're currently all the same. The quality is split into three input decimations with a range of JPEG compression factor in each. The decimations are 640x240, 320x240, and 160x120 (slightly larger when the source is PAL). Like Ron, we've found some performance knees. With JPEG at 640x240, 1 bit-per-pixel (bpp) generally looks good, and it's pretty useless to use more than 1.5bpp because the image doesn't get any better. Below .5bpp the reconstructed images have too many articacts to watch unless you're a modern artist. So the range of action for teleconferncing is only about a factor of two, between .5 and 1bpp, with frames between 10 and 20KB each. At higher input decimations there's more high-frequency components in the images, and they don't compress as well at a given JPEG quality so the frames tend to be 6 to 12KB. I don't play much with the smallest (160x120) size since it's like a postage stamp on a high-res screen and we go full speed at the larger resolutions. At that size even high compression factors results in 1.2 to 1.6bpp, and if you need to actually tell what's going on at the other end it's closer to 2bpp. The frames are 2.2 to 5KB. So tweaking these parameters gives us only a factor of 4 to 8 from blockiest to beautiful. This is nowhere near the range of network bandwidth available, leaving frame rate as the main adjustment. But a 4x to 8x improvement in frame rate is nothing to sneeze at. Another problem with supporting multiple qualities is what to do when more than one quality is requested by different clients. Right now I round-robin schedule over each of the requested qualities. If N full-speed clients request N different qualities this leads to each getting 30/N frames per second. Yuck. This is an artifact of our hardware being able to compress each frame only once, but unless you have a very fast CPU (which we'll all have someday, except it will seem slow then, too) nobody is going to want to go over the same frame several times in software, either. Maybe nv can perform compression at several qualities simultaneously. To avoid this I pin public video servers (those dishing out TV) at a single quality. I'm not suggesting that JPEG is the optimal compression method for video, just trying to point out some limits of compression. My guess is that schemes like what nv uses have even more limited scope. lance From rem-conf-request@es.net Fri Sep 17 03:53:58 1993 Received: from swan.cl.cam.ac.uk by osi-east.es.net via ESnet SMTP service id <08918-0@osi-east.es.net>; Fri, 17 Sep 1993 00:39:04 +0000 Received: from toton.cl.cam.ac.uk (user pb (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Fri, 17 Sep 1993 08:12:29 +0100 To: Toerless Eckert cc: mbone@ISI.EDU, rem-conf@es.net Subject: Re: Idle timeout for mbone applications In-reply-to: Your message of Thu, 16 Sep 93 21:14:32 +0700. <199309161915.AA26345@faui43.informatik.uni-erlangen.de> Date: Fri, 17 Sep 93 08:12:22 +0100 From: Piete Brooks Message-ID: <"swan.cl.cam.:287020:930917071244"@cl.cam.ac.uk> Yes, the basic idea makes a lot of sense. > The most easy scheme (on suns) would probably be to track /dev/kbd, and > if it's idle for more than 10 minutes deactivate the session, and > reactivate it again if the keyboard becomes active again. Of course > this would not fit all user needs, so it would of course be more > appropriate to have some kind of extensible scheme that would allow for > modifications by the local user. Indeed, at work I have a Sun 3/60 (so no audio), but I have "hi-jacked" the audio of an ELC down the corridor, and run it through the terminal patch panel into my office. This means I may well be there, but the keybaord of the ELC idle (its owner is on maternity leave). However, I *do* have an electronic tag, so the system knows which room I'm in, so it would be very useful to have an external hook. In fact, I've been meaning to ask if there is any way an external program can make VAT change my ID string to indicate whether I'm in earshot or not. I see that some of RFV sources alternate their string -- but I assume that they are special programs, rather than just a VAT hooked up to a boogie-box. Any ideas ? From rem-conf-request@es.net Fri Sep 17 04:47:02 1993 Received: from grimaldi.rutgers.edu by osi-east.es.net via ESnet SMTP service id <09405-0@osi-east.es.net>; Fri, 17 Sep 1993 01:38:15 +0000 Received: by grimaldi.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29622; Fri, 17 Sep 93 04:38:11 EDT Date: Fri, 17 Sep 93 4:38:06 EDT From: Jim Martin To: rem-conf@es.net Subject: a currious statistic Message-Id: Folks, This evening I did a netstat -s on my workstation and got a very interesting statistic. What follows is the igmp portion of that output: igmp: 12203 messages received 0 messages received with too few bytes 0 messages received with bad checksum 6079 membership queries received 0 membership queries received with invalid field(s) 6124 membership reports received 0 membership reports received with invalid field(s) 6124 membership reports received for groups to which we belong 36139 membership reports sent Is it just me or is should the number of membership reports sent be _much_ lower? How could I possibly be sending ~3 times the number of responses than the total number of igmp messages recieved? The machine in question is a Sun SS2 running 4.1.3 with all of the multicast mods (up to and including the mrouted 3.1 stuff). This is strictly a leaf node...it's not a mrouter. Forgive me if I'm missing something obvious (entirely possible at 4:30AM :), but this seems quite odd to me. Jim Jim Martin Internet: jim@noc.rutgers.edu Network Services UUCP: {backbone}!rutgers!jim Rutgers University Phone: (908) 932-3719 From rem-conf-request@es.net Fri Sep 17 07:48:38 1993 Received: from ninet.research.att.com by osi-east.es.net via ESnet SMTP service id <10073-0@osi-east.es.net>; Fri, 17 Sep 1993 04:39:17 +0000 Received: by research.att.com; Fri Sep 17 07:38 EDT 1993 Date: Fri, 17 Sep 93 07:38:06 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: Toerless.Eckert@informatik.uni-erlangen.de, Piete.Brooks@cl.cam.ac.uk Subject: Re: Idle timeout for mbone applications Cc: mbone@ISI.EDU, rem-conf@es.net The next version of Nevot will have the ability to connect to a conference controller through a TCP pipe. Through that pipe, any of the Tcl commands controlling Nevot can be send, including the command to shut down sessions or change the user identification string. If somebody sends me a bit of code that checks for keyboard idle, I might include it as an example. I believe it to be inappropriate to include these things into the media application itself since it a) is shared by a number of them and b) the definition of 'idle' (as witnessed by the discussion) differs according to circumstances, host, etc. Henning --- Henning Schulzrinne (hgs@research.att.com) AT&T Bell Laboratories (MH 2A-244) 600 Mountain Ave; Murray Hill, NJ 07974 phone: +1 908 582-2262; fax: +1 908 582-5809 From rem-conf-request@es.net Fri Sep 17 07:57:22 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <10107-0@osi-east.es.net>; Fri, 17 Sep 1993 04:51:02 +0000 Received: from cereal.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 17 Sep 1993 12:50:31 +0100 To: Bob Clements cc: tom@cic.net, dunigan@thdsun.epm.ornl.gov, rem-conf@es.net Subject: Re: vat and watchdog resets on Suns In-reply-to: Your message of "Thu, 16 Sep 93 14:29:02 EDT." <9309161829.AA00859@lion.bbn.com> Date: Fri, 17 Sep 93 12:50:28 +0100 From: Gordon Joly I run this when I start up X/OpenLook: that seems to cure the behaviour. cat $HOME/sounds/sheep2.au >/dev/audio Gordo. From rem-conf-request@es.net Fri Sep 17 10:13:23 1993 Received: from manua.gsfc.nasa.gov by osi-east.es.net via ESnet SMTP service id <10827-0@osi-east.es.net>; Fri, 17 Sep 1993 07:06:05 +0000 Received: by manua.gsfc.nasa.gov (920330.SGI/911001.SGI) for rem-conf@es.net id AA15720; Fri, 17 Sep 93 10:06:30 -0400 Date: Fri, 17 Sep 93 10:06:30 -0400 From: frank@manua.gsfc.nasa.gov (Frank Chen) Message-Id: <9309171406.AA15720@manua.gsfc.nasa.gov> To: rem-conf@es.net Subject: questions about vat, wb running on SGI Indigo I just started playing with all this multicast applications to see NASASelect and SciVis Workshop. They are great! When I ran the second vat session, it never came up and my screen has the message 'aud ctrl bind: Address already in use'. So, I need to quit the current vat session and start another vat session if I want to switch. It's a pain. I know it running fine on Sun. Another problem is that even the second vat session never came up, it did set the speaker volume to default(audio is still from the first vat session) until I click the volume control on the first vat session to return to original first vat setup. As for 'wb', It's quite easy to mess up the whiteboard by network attendee and even it has the same kind of setup for other users to take out the 'noise' by someone else, it's very difficult to actual catch that person because you only see three or four users on the default window and even that person's entry happen to be in the current user list window, you will only know he is the one when he is doing the drawing. However, the drawing stays for ever and you have to click on every users to find out who is the one out there. For vat, audio does not leave a trace like the drawing on whiteboard. Is that possible to re-arrange the user list so that the users who do the most recent drawing will show up in the user list window either by the order(most recent one get highest position) or by color(red for most recent one, green for the second, yellow for ....) Thanks! -Frank Chen =============================================================================== | Chih-Hung Chen (Frank) | email: frank@manua.gsfc.nasa.gov| | General Sciences Corp.(SAIC) | fax : (301) 286-3221 | | Software Development - SeaWiFS Data System| voice: (301) 286-9531 | | System/Network SeaWiFS Project | | | NASA/Goddard Space Flight Center | | | Code 970.2 | | | Greenbelt, Maryland 20771 | | =============================================================================== From rem-conf-request@es.net Fri Sep 17 11:20:28 1993 Received: from SKIGO.GRAPHICS.CORNELL.EDU by osi-east.es.net via ESnet SMTP service id <11452-0@osi-east.es.net>; Fri, 17 Sep 1993 08:19:48 +0000 Received: by skigo.graphics.cornell.edu (5.65/DEC-Ultrix/4.3) id AA25788; Fri, 17 Sep 1993 11:18:34 -0400 Message-Id: <9309171518.AA25788@skigo.graphics.cornell.edu> To: Piete Brooks Cc: rem-conf@es.net Subject: Re: Idle timeout for mbone applications In-Reply-To: Your message of "Fri, 17 Sep 93 08:12:22 BST." <"swan.cl.cam.:287020:930917071244"@cl.cam.ac.uk> Date: Fri, 17 Sep 93 11:18:31 -0400 From: Mitch Collinsworth X-Mts: smtp >In fact, I've been meaning to ask if there is any way an external program can >make VAT change my ID string to indicate whether I'm in earshot or not. >I see that some of RFV sources alternate their string -- but I assume that they >are special programs, rather than just a VAT hooked up to a boogie-box. >Any ideas ? The simple way to make your name flip-flop like the RFV jockeys is to run two VAT sessions at the same time with a different name in each one. Personally I find this practice annoying, as it keeps distracting my eye when I am trying to concentrate on something I'm working on in another window. Of course it wouldn't be annoying if you were only changing it when you arrive at and leave your desk, but flipping it every couple seconds is. -Mitch Collinsworth From rem-conf-request@es.net Fri Sep 17 13:41:04 1993 Received: from thdsun.EPM.ORNL.GOV by osi-east.es.net via ESnet SMTP service id <12916-0@osi-east.es.net>; Fri, 17 Sep 1993 10:40:27 +0000 Received: by thdsun.EPM.ORNL.GOV (4.1/1.34) id AA14784; Fri, 17 Sep 93 13:40:25 EDT Date: Fri, 17 Sep 93 13:40:25 EDT From: dunigan@thdsun.EPM.ORNL.GOV (Tom Dunigan 576-2522) Message-Id: <9309171740.AA14784@thdsun.EPM.ORNL.GOV> To: rem-conf@es.net Subject: a curses-based Sun tool for watching IP traffic (including mcast) /* ipwatch * compile with -lcurses -ltermcap * need to be su thd@ornl.gov * uses etherd nit mgt src, assumes le0 */ # include #include #include # include # include extern int errno; struct Stats{ char *name; int port; int count; int prev; }; struct Stats tcp[] = { "TCP",0,0,0, "telnet",23,0,0, "rlogin",513,0,0, "Xwindow",6000,0,0, "mail",25,0,0, "nntp",119,0,0, "rsh",514,0,0, "ftpdata",20,0,0, "ftp",21,0,0, "other",-1,0,0 }; struct Stats udp[] = { "UDP",0,0,0, "nfs",2049,0,0, "domain",53,0,0, "ntp",123,0,0, "who",513,0,0, "syslog",514,0,0, "snmp",161,0,0, "other",-1,0,0 }; #define Ntcp (sizeof(tcp)/sizeof(struct Stats)) #define Nudp (sizeof(udp)/sizeof(struct Stats)) char *device = "le0"; int if_fd, delay; int AllPkts,Pkts,arps,notip,ipmcasts; double KBs; main(argc,argv) char **argv; { void quit(); int fd,packet_ip(); int last,readbit, readfds; delay=5; argc--; argv++; while (argc > 0 && argv[0][0] == '-') { char *cp = *argv++; while (*++cp) switch (*cp) { case 'd': case 'f': break; default: printf("usage: ipwatch\n"); break; } } initdevice(); /* Set up the screen */ initscr(); signal(SIGINT, quit); signal(SIGTERM, quit); signal(SIGQUIT, quit); signal(SIGHUP, quit); clear(); refresh(); last = time(0); readbit = 1 << if_fd; for(;;){ readfds = readbit; if (select(32, &readfds, 0, 0, 0) < 0) { if (errno == EINTR) continue; perror("ipwatch: select"); quit(); } if (readfds & readbit) readdata(); if ((time(0) - last ) > delay) { update(); last = time(0); } } } update() { int percent, row, i,j, ndots, now; row = 0; /* update screen with plot */ now = time(0); move(0, 12); printw(" ipwatch v 1.0 ippkts %5d %s ", Pkts,ctime(&now)); if (Pkts == 0) {refresh(); return;} row = 1; move(row,0); clrtoeol(); printw("LOAD %4.0f KBs %d pps",KBs/(1000.*delay),AllPkts/delay); move(row, 25); percent = 100.*KBs/(1000.*delay*1200); printw("%3d%%",percent); move(row, 30); ndots = percent/2; while (ndots--) addch('*'); move(++row, 0); clrtoeol(); printw(" arps"); move(row, 16); printw("%5d",arps); move(row, 25); printw("%3d",arps/delay); move(row, 30); ndots = arps/delay; if (ndots > 50) ndots=50; while (ndots--) addch('*'); move(++row, 0); clrtoeol(); printw(" IPmcast"); move(row, 16); printw("%5d",ipmcasts); move(row, 25); printw("%3d",ipmcasts/delay); move(row, 30); ndots = ipmcasts/delay; if (ndots > 50) ndots=50; while (ndots--) addch('*'); row = 3; for (i=0;i #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #define BUFSPACE 4*8192 #define CHUNKSIZE 2048 #define MINPACKETLEN 60 union netheader { struct udpiphdr nh_udpipheader; struct ether_arp nh_arpheader; #define nh_ipovlyheader nh_udpipheader.ui_i #define nh_udpheader nh_udpipheader.ui_u } netheader; struct ether_header eheader; int wirelen; #define IP ((struct ip *)&netheader.nh_ipovlyheader) #define ARP (&netheader.nh_arpheader) #define TYPE (ntohs(eheader.ether_type)) struct packet { struct ether_header ts_eheader; struct ether_arp arp_header; }; struct ether_header ts_eheader; char etarget[6]; static int chunksize = CHUNKSIZE; char buf[BUFSPACE]; char *edst, *esrc; readdata() { register struct nit_bufhdr *hdrp; register struct etherstat *p; register struct etheraddrs *q; caddr_t bp, bufstop; char *packet; int cc; if ((cc = read(if_fd, buf, sizeof buf)) < 0) { perror("ipwatch: read"); exit(1); } /* * Process each packet in the chunk. */ for (bp = buf, bufstop = buf + cc; bp < bufstop; bp += hdrp->nhb_totlen) { /* * Set up pointers to successive objects * embedded in the current message. */ hdrp = (struct nit_bufhdr *)bp; packet = (char *)(hdrp + 1); bcopy(packet, (char *)&eheader, sizeof (eheader)); bcopy(packet + sizeof (eheader), (char *)&netheader, sizeof (netheader)); wirelen = hdrp->nhb_msglen; edst = (char *)&eheader.ether_dhost; esrc = (char *)&eheader.ether_shost; if (wirelen < MINPACKETLEN) { #ifdef DEBUG fprintf(stderr, "bad lnth %d dst %.2x%.2x%.2x%.2x%.2x%.2x src %.2x%.2x%.2x%.2x%.2x%.2x\n", wirelen, edst[0],edst[1],edst[2],edst[3],edst[4],edst[5], esrc[0],esrc[1],esrc[2],esrc[3],esrc[4],esrc[5]); #endif continue; } AllPkts++; KBs = KBs + wirelen; if (TYPE == ETHERTYPE_ARP) arps++; else if (TYPE == ETHERTYPE_IP) packet_ip(IP); else notip++; } /* through buffer */ } initdevice() { struct strioctl si; struct ifreq ifr; struct timeval timeout; u_long flags; if ((if_fd = open("/dev/nit", O_RDONLY)) < 0) { perror("nit open"); exit (1); } /* * Arrange to get discrete messages from the stream. */ if (ioctl(if_fd, I_SRDOPT, (char *)RMSGD) < 0) { perror("ioctl (I_SRDOPT)"); exit (1); } si.ic_timout = INFTIM; /* * Push and configure the buffering module. */ if (ioctl(if_fd, I_PUSH, "nbuf") < 0) { perror("ioctl (I_PUSH \"nbuf\")"); exit (1); } timeout.tv_sec = 1; timeout.tv_usec = 0; si.ic_cmd = NIOCSTIME; si.ic_len = sizeof timeout; si.ic_dp = (char *)&timeout; if (ioctl(if_fd, I_STR, (char *)&si) < 0) { perror("ioctl (I_STR: NIOCSTIME)"); exit (1); } si.ic_cmd = NIOCSCHUNK; si.ic_len = sizeof chunksize; si.ic_dp = (char *)&chunksize; if (ioctl(if_fd, I_STR, (char *)&si) < 0) { perror("ioctl (I_STR: NIOCSCHUNK)"); exit (1); } /* * Configure the nit device, binding it to the proper * underlying interface and setting the interface into * promiscuous mode if necessary. */ (void) strncpy(ifr.ifr_name, device, sizeof ifr.ifr_name); ifr.ifr_name[sizeof ifr.ifr_name - 1] = '\0'; si.ic_cmd = NIOCBIND; si.ic_len = sizeof ifr; si.ic_dp = (char *)𝔦 if (ioctl(if_fd, I_STR, (char *)&si) < 0) { perror("ioctl (I_STR: NIOCBIND)"); exit(1); } flags = NI_PROMISC; si.ic_cmd = NIOCSFLAGS; si.ic_len = sizeof flags; si.ic_dp = (char *)&flags; if (ioctl(if_fd, I_STR, (char *)&si) < 0) { perror("ioctl (I_STR: NIOCSFLAGS)"); exit (1); } /* * Flush the read queue, to get rid of anything that * accumulated before the device reached its final configuration. */ if (ioctl(if_fd, I_FLUSH, (char *)FLUSHR) < 0) { perror("ioctl (I_FLUSH)"); exit(1); } } packet_ip(ip) register struct ip *ip; { struct tcphdr *tp; struct udphdr *up; int i,fragmented; #ifdef DEBUG dump_packet(ip,Pkt_Lth); #endif Pkts++; tp = (struct tcphdr *)(ip + 1); up = (struct udphdr *)(ip + 1); fragmented = ip->ip_off & 0x1fff; /*non zero offset */ if (edst[0] == 1 && edst[1] == 0 && edst[2] == 0x5e ) ipmcasts++; switch (ip->ip_p) { case IPPROTO_TCP: tcp[0].count++; for(i=1;i< Ntcp-1; i++) { if (tp->th_sport == tcp[i].port || tp->th_dport == tcp[i].port ){ tcp[i].count++; break; } } if (i==(Ntcp-1)) tcp[i].count++; break; case IPPROTO_UDP: udp[0].count++; if (fragmented) up->uh_sport = 2049; /*nfs*/ for(i=1;i< Nudp-1; i++) { if (up->uh_sport == udp[i].port || up->uh_dport == udp[i].port ){ udp[i].count++; break; } } if (i==(Nudp-1)) udp[i].count++; break; default: break; } return(1); } From rem-conf-request@es.net Fri Sep 17 13:49:01 1993 Received: from thdsun.EPM.ORNL.GOV by osi-east.es.net via ESnet SMTP service id <12908-0@osi-east.es.net>; Fri, 17 Sep 1993 10:39:29 +0000 Received: by thdsun.EPM.ORNL.GOV (4.1/1.34) id AA14780; Fri, 17 Sep 93 13:39:23 EDT Date: Fri, 17 Sep 93 13:39:23 EDT From: dunigan@thdsun.EPM.ORNL.GOV (Tom Dunigan 576-2522) Message-Id: <9309171739.AA14780@thdsun.EPM.ORNL.GOV> To: rem-conf@es.net Subject: a Sun tool for watching IP multicast on your ether /* ipmcast [-v] * need to be su thd@ornl.gov * uses etherd nit mgt src (assumes le0) * -v will do hostname lookup (slowing things up) * if you have a nw.hosts, it will use that to translate * ether mac addresses to names * nw.hosts looks like: 02608c2cb786 solid 02608cac8f3f pcook 080069065c09 the002 08006906c429 zeus ... * to see your mcast clients: ipmcast | grep -v yourmrouter */ # include #include #include # include #define IN_NAME 0 #define IN_TCPSERV 1 #define IN_UDPSERV 2 char *lookup(); extern int errno; #define Ntcp (sizeof(tcp)/sizeof(struct Stats)) #define Nudp (sizeof(udp)/sizeof(struct Stats)) char *eatos(), *lookup(), *hostfnd(); char srcip[256], dstip[256]; char *device = "le0"; int if_fd, delay; int AllPkts,Pkts,arps,notip; int verbose, delta; double KBs,mKBs; main(argc,argv) char **argv; { void quit(); int fd,packet_ip(); int last,readbit, readfds; delay=5; argc--; argv++; while (argc-- > 0 && argv[0][0] == '-') { char *cp = *argv++; while (*++cp) switch (*cp) { case 'v': verbose++; break; default: printf("usage: ipmcast [-v]\n"); break; } } initdevice(); delta = time(0); signal(SIGINT, quit); signal(SIGTERM, quit); signal(SIGQUIT, quit); signal(SIGHUP, quit); readbit = 1 << if_fd; for(;;){ readfds = readbit; if (select(32, &readfds, 0, 0, 0) < 0) { if (errno == EINTR) continue; perror("ipmcast: select"); quit(); } if (readfds & readbit) readdata(); } } void quit() { delta = time(0) - delta; printf("\nall %d %d pps %6.1f KBs mcast %d %d pps %6.1f KBs\n", AllPkts, AllPkts/delta,KBs/(delta*1000.), Pkts,Pkts/delta,mKBs/(delta*1000.)); exit(0); } #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #define BUFSPACE 4*8192 #define CHUNKSIZE 2048 #define MINPACKETLEN 60 union netheader { struct udpiphdr nh_udpipheader; struct ether_arp nh_arpheader; #define nh_ipovlyheader nh_udpipheader.ui_i #define nh_udpheader nh_udpipheader.ui_u } netheader; struct ether_header eheader; int wirelen; #define IP ((struct ip *)&netheader.nh_ipovlyheader) #define ARP (&netheader.nh_arpheader) #define TYPE (ntohs(eheader.ether_type)) struct packet { struct ether_header ts_eheader; struct ether_arp arp_header; }; struct ether_header ts_eheader; char etarget[6]; static int chunksize = CHUNKSIZE; char buf[BUFSPACE]; char *edst, *esrc; readdata() { register struct nit_bufhdr *hdrp; register struct etherstat *p; register struct etheraddrs *q; caddr_t bp, bufstop; char *packet; int cc; if ((cc = read(if_fd, buf, sizeof buf)) < 0) { perror("ipmcast: read"); exit(1); } /* * Process each packet in the chunk. */ for (bp = buf, bufstop = buf + cc; bp < bufstop; bp += hdrp->nhb_totlen) { /* * Set up pointers to successive objects * embedded in the current message. */ hdrp = (struct nit_bufhdr *)bp; packet = (char *)(hdrp + 1); bcopy(packet, (char *)&eheader, sizeof (eheader)); bcopy(packet + sizeof (eheader), (char *)&netheader, sizeof (netheader)); wirelen = hdrp->nhb_msglen; edst = (char *)&eheader.ether_dhost; esrc = (char *)&eheader.ether_shost; if (wirelen < MINPACKETLEN) { #ifdef DEBUG fprintf(stderr, "bad lnth %d dst %.2x%.2x%.2x%.2x%.2x%.2x src %.2x%.2x%.2x%.2x%.2x%.2x\n", wirelen, edst[0],edst[1],edst[2],edst[3],edst[4],edst[5], esrc[0],esrc[1],esrc[2],esrc[3],esrc[4],esrc[5]); #endif continue; } AllPkts++; KBs = KBs + wirelen; if (TYPE == ETHERTYPE_IP && edst[0] == 1 && edst[1] == 0 && edst[2] == 0x5e ) packet_ip(IP); else notip++; } /* through buffer */ } initdevice() { struct strioctl si; struct ifreq ifr; struct timeval timeout; u_long flags; if ((if_fd = open("/dev/nit", O_RDONLY)) < 0) { perror("nit open"); exit (1); } /* * Arrange to get discrete messages from the stream. */ if (ioctl(if_fd, I_SRDOPT, (char *)RMSGD) < 0) { perror("ioctl (I_SRDOPT)"); exit (1); } si.ic_timout = INFTIM; /* * Push and configure the buffering module. */ if (ioctl(if_fd, I_PUSH, "nbuf") < 0) { perror("ioctl (I_PUSH \"nbuf\")"); exit (1); } timeout.tv_sec = 1; timeout.tv_usec = 0; si.ic_cmd = NIOCSTIME; si.ic_len = sizeof timeout; si.ic_dp = (char *)&timeout; if (ioctl(if_fd, I_STR, (char *)&si) < 0) { perror("ioctl (I_STR: NIOCSTIME)"); exit (1); } si.ic_cmd = NIOCSCHUNK; si.ic_len = sizeof chunksize; si.ic_dp = (char *)&chunksize; if (ioctl(if_fd, I_STR, (char *)&si) < 0) { perror("ioctl (I_STR: NIOCSCHUNK)"); exit (1); } /* * Configure the nit device, binding it to the proper * underlying interface and setting the interface into * promiscuous mode if necessary. */ (void) strncpy(ifr.ifr_name, device, sizeof ifr.ifr_name); ifr.ifr_name[sizeof ifr.ifr_name - 1] = '\0'; si.ic_cmd = NIOCBIND; si.ic_len = sizeof ifr; si.ic_dp = (char *)𝔦 if (ioctl(if_fd, I_STR, (char *)&si) < 0) { perror("ioctl (I_STR: NIOCBIND)"); exit(1); } flags = NI_PROMISC; si.ic_cmd = NIOCSFLAGS; si.ic_len = sizeof flags; si.ic_dp = (char *)&flags; if (ioctl(if_fd, I_STR, (char *)&si) < 0) { perror("ioctl (I_STR: NIOCSFLAGS)"); exit (1); } /* * Flush the read queue, to get rid of anything that * accumulated before the device reached its final configuration. */ if (ioctl(if_fd, I_FLUSH, (char *)FLUSHR) < 0) { perror("ioctl (I_FLUSH)"); exit(1); } } packet_ip(ip) register struct ip *ip; { struct tcphdr *tp; struct udphdr *up; int i,fragmented; #ifdef DEBUG dump_packet(ip,Pkt_Lth); #endif Pkts++; mKBs += wirelen; tp = (struct tcphdr *)(ip + 1); up = (struct udphdr *)(ip + 1); fragmented = ip->ip_off & 0x1fff; /*non zero offset */ strcpy(srcip, lookup(*(long *)&ip->ip_src, IN_NAME)); strcpy(dstip, lookup(*(long *)&ip->ip_dst, IN_NAME)); printf("%s>%s %d %s>%s %dt %s>%s \n", hostfnd(esrc),eatos(edst),wirelen,srcip,dstip,ip->ip_ttl, lookup(up->uh_sport, IN_UDPSERV), lookup(up->uh_dport, IN_UDPSERV)); return(1); } /* * Convert ethernet address to string. */ char * eatos(ea) u_char *ea; { static flip; /* fix to allow multiple calls in printf */ static char buf1[32],buf2[32]; char *p; if ((flip = 1-flip)) p =buf1; else p = buf2; sprintf(p, "%02x%02x%02x%02x%02x%02x", ea[0], ea[1], ea[2], ea[3], ea[4], ea[5]); return (p); } /* nw_hash.c */ #include struct hashent { long h_key; char *h_content; struct hashent *h_next; }; #define IN_NAME_TABSIZE 256 #define IN_TCPSERV_TABSIZE 256 #define IN_UDPSERV_TABSIZE 256 struct hashent *in_name_tab[IN_NAME_TABSIZE]; struct hashent *in_tcpserv_tab[IN_TCPSERV_TABSIZE]; struct hashent *in_udpserv_tab[IN_UDPSERV_TABSIZE]; struct { struct hashent **h_table; int h_tabsize; } hashtabs[] = { in_name_tab, IN_NAME_TABSIZE, in_tcpserv_tab, IN_TCPSERV_TABSIZE, in_udpserv_tab, IN_UDPSERV_TABSIZE }; char * lookup(key, type) long key; /* address or port */ int type; /* IN_NAME, IN_TCPSERV, IN_UDPSERV */ { register int hash; register int size; register struct hashent **hepp; register struct hashent *hep; struct hashent *tp; struct hostent *hp; struct servent *sp; char *name; static char buf[32]; char *sprintf(); char *malloc(); size = hashtabs[type].h_tabsize; hepp = hashtabs[type].h_table; hash = (key & 0xffff) % size; /* Only look at lower 16 bits */ for (hep = hepp[hash]; hep; hep = hep->h_next) if (hep->h_key == key) return (hep->h_content); tp = (struct hashent *) malloc(sizeof (struct hashent)); if (tp == NULL) return (NULL); tp->h_key = key; tp->h_next = NULL; switch (type) { case IN_NAME: hp = NULL; if (verbose) hp = gethostbyaddr((char *)&key, sizeof (long), AF_INET); name = (hp ? hp->h_name : inet_ntoa(*(struct in_addr *)&key)); break; case IN_TCPSERV: case IN_UDPSERV: sp = getservbyport((short)key, type == IN_TCPSERV ? "tcp" : "udp"); if (sp) { name = sp->s_name; } else if (type == IN_UDPSERV && (u_short) key == 2049) name = "nfs"; else{ sprintf(buf, "%u", (u_short) key); name = buf; } break; } tp->h_content = malloc(strlen(name)+1); strcpy(tp->h_content, name); tp->h_next = hepp[hash]; hepp[hash] = tp; return (name); } #define MAXHOSTS 2000 char hostad[MAXHOSTS][13], hostnm[MAXHOSTS][17]; int lhnm = -1; int hostfndit; char *hostfnd(id) char *id; /* binary ether addr */ { /* look up host name in host table given ether addr, if we can */ /* WARNING if no find, ptr to ascii-hex returned, with * multiple calls in printf value may be changed before * printed */ FILE *fp; int i; char *p, *eatos(); if (lhnm == -1) { /* first time */ lhnm = 0; if ((fp=fopen("nw.hosts","r")) != NULL) while (fscanf(fp,"%s %s",hostad[lhnm],hostnm[lhnm])==2)lhnm++; fclose(fp); } p = eatos(id); hostfndit=1; for (i=0;i; Fri, 17 Sep 1993 11:28:04 +0000 Received: from bugs.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA05514; Fri, 17 Sep 93 19:53:20 +0200 Message-Id: <9309171753.AA05514@sics.se> To: Piete Brooks Cc: rem-conf@es.net Subject: Re: Idle timeout for mbone applications In-Reply-To: Your message of "Fri, 17 Sep 1993 17:18:31 +0200." <9309171518.AA25788@skigo.graphics.cornell.edu> Date: Fri, 17 Sep 1993 19:52:28 +0200 From: Anders Klemets >In fact, I've been meaning to ask if there is any way an external program can >make VAT change my ID string to indicate whether I'm in earshot or not. >I see that some of RFV sources alternate their string -- but I assume that they >are special programs, rather than just a VAT hooked up to a boogie-box. >Any ideas ? I have put a program that does precisely that, vat_idle, in the file archive/vat_nv_record.tar.Z in the ftp area of sics.se. The program checks both the keyboard and the mouse, and if it thinks that you are idle (you can specify a minimum idle time) it will send a vat session message indicating the time that one has been idle. It is possible to personalize this message. The tar file also includes a program called vat_play_audio which I used for the talking clock. It takes a .au-file as input and sends it as vat packets. Silence supression can be enabled with a "-v" flag, but it does not necessarily work well for all files. Have fun, Anders From rem-conf-request@es.net Fri Sep 17 15:01:18 1993 Received: from horse.ee.lbl.gov by osi-east.es.net via ESnet SMTP service id <13692-0@osi-east.es.net>; Fri, 17 Sep 1993 11:55:46 +0000 Received: by horse.ee.lbl.gov for rem-conf@es.net (5.65/1.41) id AA10218; Fri, 17 Sep 93 11:55:39 -0700 From: mccanne@horse.ee.lbl.gov (Steven McCanne) Message-Id: <9309171855.AA10218@horse.ee.lbl.gov> To: dunigan@thdsun.epm.ornl.gov (Tom Dunigan 576-2522) Cc: rem-conf@es.net Subject: Re: a Sun tool for watching IP multicast on your ether Date: Fri, 17 Sep 93 11:55:39 PDT Another option is to use tcpdump, e.g., 'tcpdump ip multicast'. Steve From rem-conf-request@es.net Fri Sep 17 17:46:53 1993 Received: from timbuk.cray.com by osi-east.es.net via ESnet SMTP service id <15531-0@osi-east.es.net>; Fri, 17 Sep 1993 14:42:26 +0000 Received: from berserkly.cray.com by cray.com (4.1/CRI-MX 2.19) id AA11926; Fri, 17 Sep 93 16:42:24 CDT Received: by berserkly.cray.com id AA05912; 5.64/CRI-4.9; Fri, 17 Sep 93 16:42:09 -0500 Date: Fri, 17 Sep 93 16:42:09 -0500 From: dab@berserkly.cray.com (David Borman) Message-Id: <9309172142.AA05912@berserkly.cray.com> To: rem-conf@es.net Subject: Re: mrouted questions Thanks to all who replied to my query. I have picked up the fixes for the SGI multicast code from ftp.sgi.com, and now everything works just fine! -David Borman, dab@cray.com From rem-conf-request@es.net Fri Sep 17 18:20:03 1993 Received: from SGI.COM by osi-east.es.net via ESnet SMTP service id <14405-0@osi-east.es.net>; Fri, 17 Sep 1993 13:04:29 +0000 Received: from relay.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for rem-conf@es.net id AA23698; Fri, 17 Sep 93 13:04:26 -0700 Received: from xingping.esd.sgi.com by relay.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgi.sgi.com:rem-conf@es.net id AA00974; Fri, 17 Sep 93 13:04:24 -0700 Received: by xingping.esd.sgi.com (930416.SGI/911001.SGI) for @relay.sgi.com:dab@berserkly.cray.com id AA19237; Fri, 17 Sep 93 13:04:19 -0700 Date: Fri, 17 Sep 93 13:04:19 -0700 From: arc@xingping.esd.sgi.com (Andrew Cherenson) Message-Id: <9309172004.AA19237@xingping.esd.sgi.com> To: dab@berserkly.cray.com Subject: Re: mrouted questions Cc: rem-conf@es.net > From: dab@berserkly.cray.com (David A. Borman) > > Hi. I'm trying to get an mrouted tunnel set up from a Sun to > an SGI machine. The Sun is running 4.1.3 with the multicast changes > from the net (and it works just fine), the SGI is IRIX Release > 4.0.5F System V. I'm using the multicast code that came with the > SGI machine. > > I have a srcrt tunnel set up in the mrouted.conf between the two > machines (since that is all the SGI machine supports). Both machines > are sending an receiving IGMP information (seen by running mrouted in > debug mode). From the mbone/faq.txt: In the IRIX 4.0.x release, there is a bug in the kernel code that handles multicast tunnels; an unsupported fix is available via anonymous ftp from sgi.com in the sgi/ipmcast directory. See the README there for details on installing it. (where "unsupported" means customer support doesn't support it, but I do.) The encap tunnel changes are also in that directory. From rem-conf-request@es.net Sat Sep 18 12:55:11 1993 Received: from cs.uml.edu by osi-east.es.net via ESnet SMTP service id <20700-0@osi-east.es.net>; Sat, 18 Sep 1993 09:48:38 +0000 Received: by cs.uml.edu id AA09310 (5.65c+/IDA-1.4.4 for rem-conf@es.net); Sat, 18 Sep 1993 12:48:36 -0400 From: "John F. Buford" Message-Id: <199309181648.AA09310@cs.uml.edu> Subject: FINAL CFP: 1994 Intl Conf on Multimedia Computing and Systems To: rem-conf@es.net Date: Sat, 18 Sep 1993 12:48:35 -0400 (EDT) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 5514 CALL FOR PARTICIPATION 1994 International Conference on Multimedia Computing and Systems Sponsored by The IEEE Computer Society's Task Force on Multimedia Computing May 14-19, 1994 Copley Plaza Hotel Boston, Massachusetts, USA Conference Chair: Laszlo A. Belady, Mitsubishi Electric Research, USA Program Co-Chairs: Scott M. Stevens, Carnegie Mellon University, USA and Ralf Steinmetz, IBM European Network Center, Germany Multimedia systems are expected to result in the convergence of consumer electronics, computers and communications. Their applications will transform how people work, learn and play. This conference, sponsored by the IEEE Computer Society and its Task Force on Multimedia Computing, offers a world class forum for practicing engineers and researchers to report on and exchange the latest ideas in this exciting field. Immediately preceding the conference, tutorials will provide opportunities for interaction with experts in the related fields. Through this call for papers, the organizers seek contributions of high quality papers and proposals for panels or tutorials. The field of multimedia is still evolving, hence the scope of the conference is broad. We anticipate papers covering many aspects of the transmission, processing, and use of multimedia information. We encourage submissions which describe work--finished or in progress, practical development or theory--on the following or related subjects: Systems Network architecture Hardware architecture Operating systems Distributed systems Database and information systems Techniques Video compression and processing Real time scheduling Human-computer interaction Programming paradigms Content-based retrieval Applications Capture and creation of content Synthetic information and video generation Modeling and simulation Human learning Mobile computing Group collaboration Video dialtone PAPERS AND PANEL PROPOSALS Authors are requested to submit six copies of the manuscript (maximum of 20 pages) including abstract and keywords by Nov. 15, 1993. Final papers are restricted to eight IEEE model pages. The use of prototypes and demonstration video for final presentations is encouraged. Each paper must be accompanied by a submission letter that indicates the most relevant one or two conference areas and primary author contact information including: postal address, email address, telephone and Fax numbers. Important Dates: ---------------- Nov. 15, 1993: All submissions due Jan. 15, 1994: Notification of acceptance Feb. 15, 1994: Final manuscripts due Submit all papers and panel proposals to: Scott M. Stevens Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15313 USA email: sms@sei.cmu.edu Phone: 412 268-7796 Fax : 412 268-5758 TUTORIALS In addition to papers, proposals for one and two day tutorials are solicited in any of the conference areas. Proposals should include the topic area, a brief summary of the content, a schedule, and information about the instructors. Include the following information for the instructor who will handle conference correspondence: postal address, email address, telephone and fax numbers. Proposals should be submitted by November 15. 1993. Responses and instructors' kits will be sent by Jan 15, 1994. Final course notes should be submitted by Feb 15. Submit proposals for tutorials to: Erich J. Neuhold GMD-IPSI / Technische Hochschule Darmstadt Dolivostr. 15 P.O. Box 10 43 26 6100 Darmstadt Germany email: neuhold@darmstadt.gmd.de Phone: +49 6151 869-802 Fax : +49 6151 869-818 ORGANIZING AND PROGRAM COMMITTEES --------------------------------- Conference Chair: Laszlo A. Belady, Mitsubishi Electric Research, USA Program Co-Chairs: Scott M. Stevens, Carnegie Mellon University, USA and Ralf Steinmetz, IBM European Network Center, Germany Tutorial Chair: Erich Neuhold, T.H. Darmstadt, Germany Publicity Chair: John Buford, UMass Lowell, USA Exhibits Chair: William Lambert, Horizon Research, USA Publication Chair: Tibor Vais, Compuserve, USA Reg. & Finance Chair: Joseph Boykin, GTE Laboratories, USA Local Arr. Chair: Michael Bove, MIT Media Lab, USA Program Committee: Joseph Boykin, GTE Laboratories, USA John F. Buford, Univ. of Massachusetts Lowell, USA Michael Christel, Carnegie Mellon Univ., USA Roger Dannenberg, Carnegie Mellon Univ., USA Martin Fruehauf, ZGDV Darmstadt, Germany Nicolas Georganas, Univ. of Ottawa, Canada Christoph Hornung, FHG Darmstadt, Germany Tadao Ichikawa, Hiroshima University, Japan Wolfgang Klas, GMD Darmstadt, Germany Daniel T. Ling, Microsoft, USA Andrew Lipmann, MIT Media Lab, USA Thomas D.C. Little, Boston University,USA Peiya Liu, Siemens, USA Mark Miller, Apple, USA Darren New, Bellcore, USA Radu Popescu-Zeletin, GMD-Fokus, Germany Arturo Rodriguez, Kaleida, USA Masao Sakauchi, University of Tokyo, Japan Arun Sood, George Mason University, USA Otto Spaniol, RWTH Aachen, Germany ICMCS '94 1994 International Conference on Multimedia Computing and Systems SPONSORED BY THE IEEE COMPUTER SOCIETY Task Force on Multimedia Computing From rem-conf-request@es.net Sat Sep 18 21:35:13 1993 Received: from faui45.informatik.uni-erlangen.de by osi-east.es.net via ESnet SMTP service id <22395-0@osi-east.es.net>; Sat, 18 Sep 1993 18:28:16 +0000 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA03850 (5.65c-5/7.3v-FAU); Sun, 19 Sep 1993 03:27:56 +0200 Received: from faui45r.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA05165 (5.65c-5/7.3m-FAU); Sun, 19 Sep 1993 03:27:54 +0200 From: Toerless Eckert Message-Id: <199309190127.AA05165@faui43.informatik.uni-erlangen.de> Subject: Re: Idle timeout for mbone applications To: Anders Klemets Date: Sun, 19 Sep 93 3:27:10 MET DST Cc: Piete.Brooks@cl.cam.ac.uk, rem-conf@es.net In-Reply-To: <9309171753.AA05514@sics.se>; from "Anders Klemets" at Sep 17, 93 7:52 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.3 PL11] > The program checks both the keyboard and the mouse, and if it thinks > that you are idle (you can specify a minimum idle time) it will send a > vat session message indicating the time that one has been idle. It is > possible to personalize this message. WEll done, but just the opposite of what i was looking for: I am looking for a way to standardise a mechanism by which idle people's multicast application unbind from the multicast groups to reduce traffic, something which is now becoming interesting with the upcoming "real" multicastin release with pruning. Best regards Toerless From rem-conf-request@es.net Sun Sep 19 13:17:31 1993 Received: from taurus.cs.nps.navy.mil by osi-east.es.net via ESnet SMTP service id <24686-0@osi-east.es.net>; Sun, 19 Sep 1993 10:16:57 +0000 Received: by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA18877; Sun, 19 Sep 93 10:17:32 PDT Date: Sun, 19 Sep 93 10:17:32 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9309191717.AA18877@taurus.cs.nps.navy.mil> To: mbmg@nps.navy.mil, mbone@isi.edu, rem-conf@es.net Subject: MBONE broadcast lessons learned (long) Lessons learned from broadcasting the USGS Scientific Visualization Workshop in Menlo Park California on the MBONE 15-16 SEP 93: 1. No bandwidth problems were reported by the net! This was surprising since we broadcast to world (default TTL 127) with default bandwidth 125 Kbps and NASA Select audio and video were available throughout. 2. Exposure was good. We had about 12 (average) to 20 (peak) listeners. There were about 200 entries named in the nv receivers list, with some repeats. Channel surfing attracts a lot of quick checks on your program. Viewers included distant sites in Australia, Germany, and Sweden. Closest site was SRI (2 parking lots away). 3. Video lessons learned. We couldn't use the super VHS input on the frame grabber card (apparently an nv tool restriction) which was disappointing. A PictureTel 4000 videoteleconferencing station with remote camera control proved to be a great way to allow one person to control camerawork and the mbone tools simultaneously. The remote control includes the ability to preset 4 different camera angles/zooms. The four default scenes we used were wide angle shot, speaker at podium, slide screen and audience. Minor adjustments for speaker variations and zooming in on slide details were the only work required. Smooth motion on graphics displays and videos were reduced to intermittent frames (of course) - it would be nice if the broadcaster could indicate to receivers that significant motion is being lost, since it may not be apparent to folks looking at the images. Transparencies were best presented with the room lights on to permit viewing the speaker. Color slides, graphics and videos were best presented with the house lights off. Have someone ready by the light switch! 4. Audio lessons learned. We keep RE-learning the principle that audio takes just as much preparation as video. Problems included lack of microphone replacement battery, lack of long mic extension cord, excessive echo when miking the public address system, tremendous variations in speaker volume, and total dependence on the net to learn what the outgoing sound quality was really like. A good thing was establishing an audio "backchannel" with a cooperating remote site and then typing questions/answers/comments in the vat tool name field to permit communication during presentations. When all else failed having a telephone right there proved invaluable. Best mic location was on TOP of the lectern, or on a chairback in the (usually empty) front row to avoid machine noise from the front table. We had to upgrade the vat tool version half way through because we had not doublechecked it beforehand. Our apologies for poor sound quality on the first day, and thanks for "your" feedback that helped us fix it. 5. Whiteboard lessons learned. We put a plain text copy of the program schedule on the whiteboard, and that seemed to be useful. We also included ftp instructions on how to get some of the slides in postscript form via anonymous ftp to taurus.cs.nps.navy.mil:pub/mbmg/* (IP 131.120.1.13). We did not have time to get wbimport working. If we had used wbimport in a lecture mode, a dedicated page-flipper or speaker control of the whiteboard would probably have been required. The tail end of the prepared whiteboard text was a good place for listeners to put comments. 6. Tool lessons learned. We modified the vat title to indicate conference in progress/standby/returns at XXXX hours. We also did the same thing in the sd session directory tool but that spawned new sd entries everywhere (except at the source). Bug report has been submitted. 7. Bandwidth. Getting NO complaints from the world was really surprising. Timezone differences may have accounted for some of this. Next time we might consider retransmitting 12 hours out if we can find a volunteer willing to monitor the net while the tape is running. We did follow a late suggestion to mute the audio during breaks to reduce bandwidth. The audio channel had been left open to allow remote listeners to setup their systems prior to each session start. Additionally our understanding is that audio rarely gets above 50 KBps, hardly a bandwidth hog. Switching from conference to lecture mode on the vat tool had no noticeable effect. Next time we will probably try broadcasting twice simultaneously by adding a high bandwidth/high-framerate channel with a very short TTL for adjacent sites. 8. Summary. Our initial motivation in broadcasting this workshop was to learn how to do it. We definitely learned a lot. We also hope that the SciVis presentations were of use to people on the net too. We welcome any further feedback you might want to give us. regards, Don Donald P. Brutzman LCDR USN work (408) 656-2149 Code OR/Br Naval Postgraduate School [Glasgow 204] fax (408) 656-2595 Monterey California 93943-5000 USA home (408) 372-0190 From rem-conf-request@es.net Mon Sep 20 04:52:39 1993 Received: from sics.se by osi-east.es.net via ESnet SMTP service id <28098-0@osi-east.es.net>; Mon, 20 Sep 1993 01:44:47 +0000 Received: from bugs.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA08338; Mon, 20 Sep 93 10:44:18 +0200 Message-Id: <9309200844.AA08338@sics.se> To: Toerless Eckert Cc: Piete.Brooks@cl.cam.ac.uk, rem-conf@es.net Subject: Re: Idle timeout for mbone applications In-Reply-To: Your message of "Sun, 19 Sep 1993 03:27:10 +0700." <199309190127.AA05165@faui43.informatik.uni-erlangen.de> Date: Mon, 20 Sep 1993 10:44:17 +0200 From: Anders Klemets > WEll done, but just the opposite of what i was looking for: I am > looking for a way to standardise a mechanism by which idle people's > multicast application unbind from the multicast groups to reduce traffic, > something which is now becoming interesting with the upcoming > "real" multicastin release with pruning. Oh, ok, I have now written another program that does precisely that. The program should work completely independently of any multicast application so there is little need for standardization. The program works like this: it monitors idle time of the mouse and keyboard. When one has been idle for more than a certain time (which can be specified with an "-m" flag) it changes the reference count of the IP multicast group in the kernel and causes it to be removed from the linked list in the kernel. When activity is again detected at console, the reference count is restored and the tranmission of an IGMP Membership Report message is triggered. The program operates on only one multicast group at the time (which is specified with the "-i" flag) but it could easily be extended to operate on all multicast groups. When one leaves a group it may take some time until the mrouted stops routing multicast packets for that group onto the subnet. The problem is that there is no such thing as an IGMP "Leavegroup" message. Mrouted detects that a certain group has no members by the lack of membership reports. This program (idle_detach) is available with ftp from sics.se. The filename is archive/idle_detach.c. It runs on my SunOS 4.1.3 system. Use at your own risk. Please note that the program must run as root as it writes to kernel memory. Anders From rem-conf-request@es.net Mon Sep 20 22:23:59 1993 Received: from uvaarpa.Virginia.EDU by osi-east.es.net via ESnet SMTP service id <09206-0@osi-east.es.net>; Mon, 20 Sep 1993 19:17:47 +0000 Received: from server.cs.virginia.edu by uvaarpa.virginia.edu id aa25681; 20 Sep 93 22:17 EDT Received: from phil.cs.Virginia.EDU by uvacs.cs.virginia.edu (4.1/5.1.UVA) id AA05034; Mon, 20 Sep 93 22:17:37 EDT Posted-Date: Mon, 20 Sep 93 22:17:36 EDT Return-Path: Received: by phil.cs.Virginia.EDU (4.1/SMI-2.0) id AA00531; Mon, 20 Sep 93 22:17:36 EDT Date: Mon, 20 Sep 93 22:17:36 EDT From: asw2s@phil.cs.virginia.edu Message-Id: <9309210217.AA00531@phil.cs.Virginia.EDU> To: rem-conf@es.net Subject: Multicast support in SunOS 4.1.X kernel All, Does anyone know where I can find a public distribution of the multicast support for the SunOS 4.1.X kernel? I am writing some communication code that can uses multicast and I am unable to register multicast addresses through the ioctl interface to the ethernet interface. Thank you for your time! - Alex Waterman Alex@virginia.edu From rem-conf-request@es.net Tue Sep 21 16:16:35 1993 Received: from ibminet.awdpa.ibm.com by osi-east.es.net via ESnet SMTP service id <16423-0@osi-east.es.net>; Tue, 21 Sep 1993 13:09:58 +0000 Received: by ibminet.awdpa.ibm.com (5.61/1.15) id AA21943; Tue, 21 Sep 93 13:10:34 -0700 Received: from kiwi.heidelbg.ibm.com by ibmpa.awdpa.ibm.com (5.65b(em1)/2.06) id AA24189; Tue, 21 Sep 93 13:08:09 -0700 Received: by kiwi.heidelbg.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA16422; Tue, 21 Sep 1993 22:07:59 +0200 From: ibmpa!kiwi.heidelbg.ibm.com!luca@ibminet.awdpa.ibm.com (Luca Delgrossi) Message-Id: <9309212007.AA16422@kiwi.heidelbg.ibm.com> Subject: ST-II and RSVP paper To: st%ibminet.awdpa.ibm.com@ibmpa.heidelbg.ibm.com (ST WG Discussion List), rem-conf%es.net@ibmpa.heidelbg.ibm.com (Rem-Conf WG Discussion List), end2end-interest%isi.edu@ibmpa.heidelbg.ibm.com (End2End Interest) Date: Tue, 21 Sep 1993 22:07:58 +0100 (DFT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1127 The discussion on ST-II and RSVP is certainly of high interest. This is to announce the paper: 'Reservation Protocols for Internetworks: A Comparison of ST-II and RSVP'. You may retrieve the extended abstract for the paper via anonymous ftp to "ibminet.awdpa.ibm.com" in the "pub/st" directory (format is PostScript). The paper has been accepted at the 4th Workshop on Network & Operating System Support for Digital Audio and Video, Lancaster (UK), Nov. 1993. Any comments are welcome! Luca -- +-------------------------------------------------------------------+ | Luca Delgrossi luca@ibmpa.awdpa.ibm.com | +----------------------------------+--------------------------------+ | IBM European Networking Center | INET: luca@ibmpa.awdpa.ibm.com | | Distributed Multimedia Solutions | EARN: luca@dhdibm1.bitnet | | Vangerowstr. 18 | VNET: LUCA at HEIDELBG | | D69115 Heidelberg 1 | tel : +49-6221-594330 | | Germany | fax : +49-6221-593400 | +----------------------------------+--------------------------------+ From rem-conf-request@es.net Tue Sep 21 16:20:55 1993 Received: from ietf.cnri.reston.va.us by osi-east.es.net via ESnet SMTP service id <16485-0@osi-east.es.net>; Tue, 21 Sep 1993 13:14:13 +0000 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07137; 21 Sep 93 15:39 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: rem-conf@es.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ietf-avt-encodings-02.txt Date: Tue, 21 Sep 93 15:39:33 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9309211539.aa07137@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Media Encodings Author(s) : H. Schulzrinne Filename : draft-ietf-avt-encodings-02.txt Pages : 7 This document describes a possible structure of the media content for audio and video for Internet applications. The definitions are independent of the particular transport mechanism used. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-avt-encodings-02.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-avt-encodings-02.txt". For questions, please mail to internet-drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ietf-avt-encodings-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-encodings-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart-- From rem-conf-request@es.net Tue Sep 21 16:27:55 1993 Received: from ietf.cnri.reston.va.us by osi-east.es.net via ESnet SMTP service id <16586-0@osi-east.es.net>; Tue, 21 Sep 1993 13:21:23 +0000 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07167; 21 Sep 93 15:39 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: rem-conf@es.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ietf-avt-profile-02.txt Date: Tue, 21 Sep 93 15:39:51 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9309211539.aa07167@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Sample Profile for the Use of RTP for Audio and Video Conferences with Minimal Control Author(s) : H. Schulzrinne Filename : draft-ietf-avt-profile-02.txt Pages : 5 This note describes a profile for the use of the real-time transport protocol (RTP) and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from content index to encodings. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-avt-profile-02.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-avt-profile-02.txt". For questions, please mail to internet-drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ietf-avt-profile-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart-- From rem-conf-request@es.net Tue Sep 21 18:34:00 1993 Received: from optics.wc.novell.com by osi-east.es.net via ESnet SMTP service id <18503-0@osi-east.es.net>; Tue, 21 Sep 1993 15:26:17 +0000 Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AB01906; Tue, 21 Sep 93 15:18:27 PDT Date: Tue, 21 Sep 93 15:18:27 PDT Message-Id: <9309212218.AB01906@wc.novell.com> To: Jim Martin From: minshall@wc.novell.com X-Sender: minshall@optics.wc.novell.com Subject: Re: a currious statistic Cc: rem-conf@es.net Jim, Apologies to you (and the list) if this has already been answered... > This evening I did a netstat -s on my workstation and got a >very interesting statistic. What follows is the igmp portion of that >output: >igmp: > 12203 messages received > 0 messages received with too few bytes > 0 messages received with bad checksum > 6079 membership queries received > 0 membership queries received with invalid field(s) > 6124 membership reports received > 0 membership reports received with invalid field(s) > 6124 membership reports received for groups to which we belong > 36139 membership reports sent > > Is it just me or is should the number of membership reports >sent be _much_ lower? How could I possibly be sending ~3 times the >number of responses than the total number of igmp messages recieved? The number of IGMP replies sent is a (non-deterministic) function of (# of queries received, # of groups on this machine, # of other machines on the network). So, if your machine is the *only* machine on a network for 3 different groups, you would expect to send three membership reports for each membership query received. Or, am i missing something? Greg Minshall From rem-conf-request@es.net Wed Sep 22 03:57:12 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <22975-0@osi-east.es.net>; Wed, 22 Sep 1993 00:48:48 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 22 Sep 1993 08:48:10 +0100 To: luca@ibminet.awdpa.ibm.com (Luca Delgrossi) cc: st (ST WG Discussion List) , rem-conf (Rem-Conf WG Discussion List) , end2end-interest (End2End Interest) Subject: Re: ST-II and RSVP paper In-reply-to: Your message of "Tue, 21 Sep 93 22:07:58 BST." <9309212007.AA16422@kiwi.heidelbg.ibm.com> Date: Wed, 22 Sep 93 08:48:08 +0100 From: Jon Crowcroft well that message sure messed up my reply fields! >is to announce the paper: 'Reservation Protocols for Internetworks: A >Comparison of ST-II and RSVP'. this is an excellent clear paper - however, you absolutely have to be aware of the background work on a) multicast b) resource reservation c) RTP and other real time protocols d) conference control there is a lot of expereince in the way multicast conferences happen IN REALITY o nthe mbone that leads to the RSVP model very naturally (e.g. the fact that hmas do audio floor control very nicely being one key factor) and there is a lot of experience from use of ST (e.g. o nthe wideband satellite net, the TWBnet and DSInet) as well as in the implementation work by partridge and pink... I wish people (agencies:-) would recognize that ST (and similar efforts [c.f. xtp) were pilots for ideas ahead of their time, and should be discarded for new developments that subsume their functionaility and later developments! jon From rem-conf-request@es.net Wed Sep 22 06:26:47 1993 Received: from ibminet.awdpa.ibm.com by osi-east.es.net via ESnet SMTP service id <23550-0@osi-east.es.net>; Wed, 22 Sep 1993 03:18:02 +0000 Received: by ibminet.awdpa.ibm.com (5.61/1.15) id AA28550; Wed, 22 Sep 93 03:18:40 -0700 Received: from [9.228.10.104] by ibmpa.awdpa.ibm.com (5.65b(em1)/2.06) id AA09277; Wed, 22 Sep 93 03:15:13 -0700 Received: by kiwi.heidelbg.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17008; Wed, 22 Sep 1993 12:14:15 +0200 From: ibmpa!kiwi.heidelbg.ibm.com!luca@ibminet.awdpa.ibm.com (Luca Delgrossi) Message-Id: <9309221014.AA17008@kiwi.heidelbg.ibm.com> Subject: Re: ST-II and RSVP paper To: J.Crowford%cs.ucl.ac.uk@ibmpa.heidelbg.ibm.com (Jon Crowford) Date: Wed, 22 Sep 1993 12:14:14 +0100 (DFT) Cc: st%ibminet.awdpa.ibm.com@ibmpa.heidelbg.ibm.com (ST WG Discussion List), rem-conf%es.net@ibmpa.heidelbg.ibm.com (Rem-Conf WG Discussion List), end2end-interest%isi.edu@ibmpa.heidelbg.ibm.com (End2End Interest) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4792 Jon, Jon Crowcroft: > > well that message sure messed up my reply fields! > sorry, I will try and fix the problem with the e-mail reply. The correct address for the ST Working Group Discussion List is: st@ibminet.ibm.com > >is to announce the paper: 'Reservation Protocols for Internetworks: A > >Comparison of ST-II and RSVP'. > > this is an excellent clear paper - however, you absolutely have to be > aware of the background work on > > a) multicast > b) resource reservation > c) RTP and other real time protocols > d) conference control > we are aware of the work going on in the areas you mentioned and we are of course monitoring it with much interest. ST is exactly an answer to many of the points you mention as multicast, resource reservation etc. Nevertheless, people tend to forget what ST brings, as for example in your recent paper on multicast congestion control: > there is a lot of experience in the way multicast conferences happen > IN REALITY o nthe mbone that leads to the RSVP model very naturally > (e.g. the fact that hmas do audio floor control very nicely being one > key factor) ... I have to disagree when you say that conferencing leads naturally to the RSVP model. This is true for multicast conferences where a very large number of participants is involved. This seems to be the only kind of conferencing people can think of! ST can be easily used for conferencing among a small number of participants (by the way, they are the most productive ones), for conferences where there is a single speaker and the audience can talk to the speaker only (as in a lecture) and can also be easily extended to do more (which we have done, see paper below). The two protocols have different properties and one or the other can be more appropriate for specific scenarios. While conferencing is certainly an important aspect, we should not forget the other aspects of distributed multimedia, as TV distribution, video-on-demand, last-minute training, multimedia mail, etc. I don't think that it is possible to say that RSVP solves all the problems. I feel that there is not enough effort put in multimedia within the Internet community. Therefore I welcome RSVP, ST, and any other solutions. > ... and there is a lot of experience from use of ST (e.g. o > nthe wideband satellite net, the TWBnet and DSInet) as well as in the > implementation work by partridge and pink... Please do not forget the work on ST we have done at the ENC. We have fully implemented the protocol tightly coupled with a resource reservation model. I think the result is original and successful. We are using ST with several multimedia platforms and applications. I will make available via ftp a paper describing our implementation (which has been accepted by Interneworking: Research and Experience) and a second one on: "Receiver-Initiated Communication with ST2". I look forward to your comments on those as well. > I wish people (agencies:-) would recognize that ST (and similar > efforts [c.f. xtp) were pilots for ideas ahead of their time, and > should be discarded for new developments that subsume their > functionaility and later developments! > On the contrary, due to our and other people work, ST is experiencing a revival these days. It has been chosen in Europe as part of the BERKOM Multimedia Transport supported by several major IT companies, it has at least 13 existing implementations, and a Working Group has been established at the IETF (this is what the ST WG Discussion List is all about) to review the specs. RSVP work does not subsume ST for many reasons, the simplest being ST carries data, RSVP does not. In the research field we tend to discard ideas or to forget about them before enough results have been produced. I feel ST is one of these cases. What I would really like to see, is that efforts on ST and RSVP converge at some point, for instance to produce a common, well-understood, agreed on, flow specification. > jon > > Thanks for your comments, Luca -- +-------------------------------------------------------------------+ | Luca Delgrossi luca@ibmpa.awdpa.ibm.com | +----------------------------------+--------------------------------+ | IBM European Networking Center | INET: luca@ibmpa.awdpa.ibm.com | | Distributed Multimedia Solutions | EARN: luca@dhdibm1.bitnet | | Vangerowstr. 18 | VNET: LUCA at HEIDELBG | | D69115 Heidelberg 1 | tel : +49-6221-594330 | | Germany | fax : +49-6221-593400 | +----------------------------------+--------------------------------+ From rem-conf-request@es.net Wed Sep 22 06:39:09 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <23620-0@osi-east.es.net>; Wed, 22 Sep 1993 03:38:25 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 22 Sep 1993 11:37:24 +0100 To: luca@ibminet.awdpa.ibm.com (Luca Delgrossi) cc: st@ibminet.ibm.com, rem-conf (Rem-Conf WG Discussion List) , end2end-interest (End2End Interest) Subject: Re: ST-II and RSVP paper In-reply-to: Your message of "Wed, 22 Sep 93 12:14:14 BST." <9309221014.AA17008@kiwi.heidelbg.ibm.com> Date: Wed, 22 Sep 93 11:37:20 +0100 From: Jon Crowcroft > guarantee QoS, and especially not for multicast continuous media > service.> however, we are very close to having very good scalable schemes in place! (see CSZ papers for example...) >I have to disagree when you say that conferencing leads naturally to >the RSVP model. This is true for multicast conferences where a very >large number of participants is involved. This seems to be the only >kind of conferencing people can think of! ST can be easily used for >conferencing among a small number of participants (by the way, they >are the most productive ones), for conferences where there is a single >speaker and the audience can talk to the speaker only (as in a >lecture) and can also be easily extended to do more (which we have done, >see paper below). but if RSVP works wel lfor large conferences, then it works even beter for small ones! >Please do not forget the work on ST we have done at the ENC. We have >fully implemented the protocol tightly coupled with a resource >reservation model. I think the result is original and successful. sure...sorry i forgot to mention it! >We are using ST with several multimedia platforms and applications. >I will make available via ftp a paper describing our implementation >(which has been accepted by Interneworking: Research and Experience) >and a second one on: "Receiver-Initiated Communication with ST2". that will be very interesting to see... >I look forward to your comments on those as well. >> efforts [c.f. xtp) were pilots for ideas ahead of their time, and >> should be discarded for new developments that subsume their >> functionaility and later developments! >On the contrary, due to our and other people work, ST is experiencing >a revival these days. It has been chosen in Europe as part of the >BERKOM Multimedia Transport supported by several major IT companies, >it has at least 13 existing implementations, but BERKOM is working largely over ATM is it not, which provides most of the functioaility (circtuit management, bandwidth guarantees, call control/signalling, multicast distribution) BELOW the ST protocol - i don't understand what functionality an ST layer adds in that stack? [aside: q93b seems to make many of the same design mistakes for signalling as ST-II, however, it has the excuse that it has to be backwards comaptible with Q.931...] >and a Working Group has been established at the IETF (this is what the >ST WG Discussion List is all about) to review the specs. >RSVP work does not subsume ST for many reasons, the simplest being ST >carries data, RSVP does not. RSVP doesnt have carry data, to since IP+multicast does, and IP+multicast+resource guarantees (by WFQ or other queueing mechanism + a flow spec through rsvp) provide a scalable solution... >In the research field we tend to discard ideas or to forget >about them before enough results have been produced. I feel ST is one >of these cases. What I would really like to see, is that efforts on ST >and RSVP converge at some point, for instance to produce a common, >well-understood, agreed on, flow specification. flow specification work has moved on in the broadband/multiservice world - most of the debate seems to be heading towards a grand simplification - basically, the argument is over what 'equivalent bandwith' number the user exchanges wih the network reservation system - other numbers such as delay and error are consequential on this, or on trivial things like the fact that you need echo cancellors, or human-human interaction, or comprehension of audio etc etc... personally, i believe, the set of parameters ST had in were TOO MANY to experiement with - its too large a search space to play with... similarly with all the old RACE QoS work! I certainly look forward to research results using any valuble tool to hand, though regards jon From rem-conf-request@es.net Wed Sep 22 11:51:26 1993 Received: from ibminet.awdpa.ibm.com by osi-east.es.net via ESnet SMTP service id <25436-0@osi-east.es.net>; Wed, 22 Sep 1993 08:43:15 +0000 Received: by ibminet.awdpa.ibm.com (5.61/1.15) id AA01167; Wed, 22 Sep 93 08:43:54 -0700 Received: from muddy.awdpa.ibm.com by ibmpa.awdpa.ibm.com (5.65b(em1)/2.06) id AA16384; Wed, 22 Sep 93 08:38:56 -0700 Received: by muddy.awdpa.ibm.com (AIX 3.2/UCB 5.64/4.10) id AA26768; Wed, 22 Sep 1993 08:33:52 -0700 From: steve@ibmpa.awdpa.ibm.com (Steve DeJarnett) Message-Id: <9309221533.AA26768@muddy.awdpa.ibm.com> Subject: Re: ST-II and RSVP paper To: rem-conf@es.net, st@ibminet.awdpa.ibm.com (ST Working Group Discussion List), end2end-interest@isi.edu Date: Wed, 22 Sep 1993 08:33:51 -0800 (PDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 365 Jon Crowcroft wrote: >well that message sure messed up my reply fields! Luca sent out a note stating that gave an incorrect address for the ST mailing list. The "correct" address is: st@ibminet.awdpa.ibm.com Luca's was missing the ".awdpa" part. We're working on fixing the problem that caused the mangled reply addresses in the first place. FYI, Steve From rem-conf-request@es.net Wed Sep 22 13:10:59 1993 Received: from motgate.mot.com by osi-east.es.net via ESnet SMTP service id <26733-0@osi-east.es.net>; Wed, 22 Sep 1993 10:10:22 +0000 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15 for ) id AA12442; Wed, 22 Sep 1993 12:10:19 -0500 Received: from phx.sectel.mot.com (rambo.phx.sectel.mot.com) by pobox.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15 for ) id AA14344; Wed, 22 Sep 1993 12:10:16 -0500 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA05971; Wed, 22 Sep 93 10:10:21 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA47645; Wed, 22 Sep 1993 10:12:50 MST Message-Id: <00112.2831537570.47645@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: rem-conf@es.net (rem-conf) From: Dave_Gustafson@poncho.phx.sectel.mot.com (Dave Gustafson) Date: Wed, 22 Sep 1993 10:07:54 MST Subject: Re: FWD>Interest in ST-II (p Reply to: RE>FWD>Interest in ST-II (possible can get a draft copy of any documents developed for the internet? thanks in advance dave gustafson Motorola -------------------------------------- Date: 6/15/93 9:40 AM To: Dave Gustafson From: Paul Lambert FYI, More stuff on IP video conferencing. Paul -------------------------------------- Date: 6/14/93 5:49 PM From: rem-conf Received: from ilbe.mot.com by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA2822924986; Mon, 14 Jun 1993 17:49:46 MST Received: by ilbe.mot.com (5.65/1.6) id AA14773; Mon, 14 Jun 93 19:44:10 -0500 Date: 14 Jun 93 12:16:49 -0800 Sender: steve@ibmpa.awdpa.ibm.com From: Steve DeJarnett Reply-To: rem-conf@es.net To: ietf@IETF.CNRI.Reston.VA.US Subject: Interest in ST-II (possible BOF) Message-Id: <9306141916.AA16374@muddy.awdpa.ibm.com> X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4912 Interest in networked multimedia has grown dramatically in the past 2 years, especially with the increased use of the MBONE. IETF interest is definitely increasing, as is evidenced by the AVT working group, the new confctl working group, and the rem-conf metalist. As groups start to address pieces of the multimedia puzzle, the desire to use existing infrastructure is high and quite understandable. As David Clark pointed out at his BOF at the Columbus IETF, however, there needs to be some specialized functions added to routers and hosts to efficiently deal with networked multimedia. BOFs to address resource reservation, flow specs, and so forth are certainly coming. However, one protocol developed by the IETF has been conspicuously absent from most discussions -- ST-II. ST-II is at the heart of the German BERKOM project which will be used to link the existing government offices in Bonn with the new offices in Berlin. ST-II also forms the basis of the Defense Simulation Internet, and IBM has been working on some new products that will use ST-II to provide the networking support for multimedia. Thus, there is certainly industry interest in ST-II today. One problem with the current implementations is that they were all generally built with only similar implementations to test against. Thus, heterogeneous interoperability has not been tested. With the advent of the BERKOM project, the need to interoperate between heterogeneous systems has become very important. IBM is aware of 3 ST-II implementations that are completed (2 of which have been tested for interoperability), and at least 3 more under development for BERKOM. If the IETF community is aware of more, please let us know. Brief Implementation Overviews ------------------------------ The three implementations are very briefly described here. The IBM implementation of ST-II is done entirely in user-mode in order to ease portability between operating systems with different designs and targets (Unix, OS/2, DOS). An upcall/downcall mechanism is used to pass control between the various layers as data is received. The IBM implementation implements all PDUs excpet ERROR-IN-RESPONSE and HID-CHANGE-REQUEST. In addition, the following parameters are not implemented: FreeHIDs, Group, MulticastAddress, OriginTimestamp, RecordRoute R-parameters, and SourceRoute. Craig Partridge and Steven Pink, working at the Swedish Institute for Computer Science (SICS), developed an ST-II implementation for Sun Sparcstations. This is a more-traditional Unix kernel-mode implementation and includes a socket interface. The SICS ST-II implementation implements all PDUs except CHANGE, CHANGE-REQUEST, and HID-CHANGE-REQUEST. In addition, the following parameters are not implemented: FreeHIDs, Group, MulticastAddress, OriginTimestamp, RecordRoute, and SourceRoute. BBN has two implementations of ST-II. The first is their public-domain Sun Sparcstation version. It is also a traditional kernel-mode implementation which provides a socket interface. The second BBN implementation is in their T/20 router. This software was developed for the Defense Simulation Internet (DSI) project and is in use today at dozens of US Military sites. I'll let BBN add more about their implementations as I've left my notes at home about what they have and have not implemented. Given these implementations, ST-II is starting to reach a maturity level where software companies, who generally try to leverage anything they can to get their product to market faster, may consider using ST-II as a basis for providing networking support for new multimedia applications and services. The Punch Line -------------- Given the implementation experience that has been gained in these implementations and the fact that people may start to use ST-II implementations in production environments in the near future, perhaps it's time to review the current status of ST-II. To that end, we want to see who else might have an interest in ST-II. The purpose of this BOF would be to find out what level of interest exists in ST-II, how ST-II might be used as the network layer under RTP and other transport protocols, what extensions to ST-II might be desired or required given the current level of experience with multimedia networking, and what the future of ST-II is, especially with regard to the IESG standards track. We may be too late for a BOF at Amsterdam, but please send back responses anyway. If there is sufficient interest, but not enough time/space to schedule something at Amsterdam, we can try for Houston. Thanks, Steve DeJarnett IBM Personal Systems Multimedia steve@ibmpa.awdpa.ibm.com P.S. -- I've set Reply-to: to rem-conf@es.net to try to keep the discussion traffic off the ietf list. We'll see if this succeeds... :-) Apologies in advance to any rem-conf-ites who aren't interested. From rem-conf-request@es.net Wed Sep 22 17:05:43 1993 Received: from sics.se by osi-east.es.net via ESnet SMTP service id <01152-0@osi-east.es.net>; Wed, 22 Sep 1993 13:58:09 +0000 Received: from bugs.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA16191; Wed, 22 Sep 93 22:58:05 +0200 Message-Id: <9309222058.AA16191@sics.se> To: rem-conf@es.net Subject: Sun FDDI/S IP multicast support Date: Wed, 22 Sep 1993 22:58:04 +0200 From: Anders Klemets This is to announce the availability of a SunOS kernel patch that enables IP multicast for the Sun FDDI/S driver. The distribution includes a number of files, but all that is needed for simple IP multicast support is the file fddi_fix_for_multicast.o. It may also be necessary to patch the loadable device driver bf.o with an editor, replacing all occurrences of "arpinput" and "arpresolve" with "ARPinput" and "ARPresolve", respectively. Unfortunately, since I have no source code for the FDDI driver, I have not been able to make the FDDI driver listen promiscuously on all multicast groups. Although not necessary for normal operation, this turns out to be a crucial feature if one is going to run mrouted. With only these patches, mrouted will not work over the FDDI interface. This might not matter in some situations, for instance if the FDDI ring is used in a LAN setting and another machine is running mrouted. (This other machine would have to use some other FDDI interface that works with mrouted, such as the one from Cresendo.) In a FDDI WAN or MAN setting where FDDI ring is used to interconnect LAN's, an mrouted would typically have to run at each site. Here we have a problem. A possible solution would be to set the FDDI interface in full promiscous mode, which would be acceptable if the FDDI ring is only used for multicast trafffic. Since it is not possible to change the driver to allow promiscous reception of multicast packets only, I have instead changed the multicast routing code in such a way that promiscous reception is no longer required. I implemented point to multipoint tunnels. This is not as bad as normal tunnels, since only one multipoint tunnel is needed to reach all other routers on the FDDI ring. To configure a multipoint tunnel one would put something like this in /etc/mrouted.conf phyint x.x.x.x disable tunnel x.x.x.x 224.0.0.50 metric 1 where x.x.x.x should be replaced with the IP address of the FDDI interface. The tunnel endpoint should be a multicast address that is numerically less than 224.0.0.255. This appears to be working, but I give no guarantees. Consider it to be very, very, beta. I make the code available mainly because I don't have much time to spend testing and debuging it. Any help would be greatly appreciated. The code includes plenty of changes to mrouted and a minor change to netinet/ip_mroute.c. The basic IP multicast support in fddi_fix_for_multicast.o should not cause any problems however. I wrote it about six months ago, but didn't realize that the code was actually working until earlier this week. I don't think I can make the source available because it includes modified versions of addmultiaddr() and delmultiaddr() which were originally taken from the Sun sources for sunif/if_subr.c. The fddi_fix_for_multicast.o file goes in the OBJ directory in the kernel source tree. If you have a netinet/fddi_fix_for_multicast.c file already, it should be removed or renamed. Make sure it is listed in conf/files or conf.common/files.cmn however. Don't forget to run config before you run make. The code for all of this is available with ftp from sics.se. The filename is archive/fddimcast.tar.Z. You may want to save this message if you are going to use the code. What you have just read is the documentation. Good luck, Anders From rem-conf-request@es.net Wed Sep 22 22:14:15 1993 Received: from alpha.Xerox.COM by osi-east.es.net via ESnet SMTP service id <05115-0@osi-east.es.net>; Wed, 22 Sep 1993 19:07:04 +0000 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12291(3)>; Wed, 22 Sep 1993 19:06:40 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 22 Sep 1993 19:06:37 -0700 To: rem-conf@es.net, mbone@isi.edu Subject: Xerox PARC Forum, Thursday, September 23 -- Alan Kay Date: Wed, 22 Sep 1993 19:06:23 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Sep22.190637pdt.12171@skylark.parc.xerox.com> The following seminar will be 'cast on the MBone, using the same TTL scope as IETF Channel 2. It is advertised in 'sd' with the following parameters: Xerox PARC Forum - Audio pcm 224.2.199.198, port 49373, id 0, ttl 159 Xerox PARC Forum - Video nv 224.2.199.199, port 49375, id 0, ttl 95 Thursday, September 23, 1993 4:00 P.M. Pacific Daylight Time (2300 GMT) PARC Auditorium "The Best Way to Predict the Future Is to Invent It" Alan Kay, Apple Fellow, Apple Computer Historically, humans have extended themselves in two principal ways. First, by creating amplifying tools -- physical and abstract structures that can be manipulated -- such as the wheel, telescope, language, writing, mathematics. Second, by discovering how to get others to absorb goals -- physical and abstract processes that can be managed -- such as individuals, clubs, businesses, religions, countries, cultures. The metaphors of manipulation and management were immediately applied to human-computer communication in the late '50s when researchers first realized that the computer was a medium for extension and not just a calculation engine. The user interface -- a simplifying metaphor theatrically portrayed -- is the only "computer" most people ever see. Most of the successful designs so far have been of the manipulative amplifying tool type -- Xerox PARC windows and pointing interface, spreadsheets, the Macintosh -- but now there is an ever increasing need for interfaces that can absorb goals and be managed. Though not much has yet been discovered about how human mentalities really function, the little that is known is both nonintuitive and crucial to the design process. Though we seem to have the same level of intelligence as thousands of years ago, our much more powerful contexts greatly amplify our ability to think. A user interface matched to human psychology provides a context for thinking and acting whose amplification can be truly remarkable. As human and technological systems explode with capacity and complexity, the user interface designs of the future will be the principal path to simplicity and control. From rem-conf-request@es.net Wed Sep 22 22:40:49 1993 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <05262-0@osi-east.es.net>; Wed, 22 Sep 1993 19:34:28 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Wed, 22 Sep 1993 19:30:34 -0700 Posted-Date: Wed 22 Sep 93 19:29:52 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Wed, 22 Sep 93 19:29:53 PDT Date: Wed 22 Sep 93 19:29:52 PDT From: Stephen Casner Subject: Re: ST-II and RSVP paper To: J.Crowcroft@cs.ucl.ac.uk Cc: st@ibminet.awdpa.ibm.com, rem-conf@es.net, END2END-INTEREST@ISI.EDU Message-Id: <748751392.0.CASNER@XFR.ISI.EDU> In-Reply-To: <199309221038.AA29747@venera.isi.edu> Mail-System-Version: Jon, This statement always bugs me: > personally, i believe, the set of [flowspec] parameters ST had in > were TOO MANY to experiement with - its too large a search space to > play with... similarly with all the old RACE QoS work! The initial ST-II flowspec had 14 parameters, of which two were really return values, not parameters. In Craig Partridge's grand reduction of parameters for the flowspec in RFC 1363, there are 10 parameters, which doesn't sound so different to me. I'm not claiming that the ST flowspec had the right set of parameters; it was our first pass and was intended to be changed. The ST spec states "the FlowSpec will need to be revised as experience is gained". -- Steve ------- From rem-conf-request@es.net Thu Sep 23 03:20:20 1993 Received: from mitsou.inria.fr by osi-east.es.net via ESnet SMTP service id <06289-0@osi-east.es.net>; Thu, 23 Sep 1993 00:12:22 +0000 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA13171; Thu, 23 Sep 1993 09:13:45 +0200 Message-Id: <199309230713.AA13171@mitsou.inria.fr> To: Stephen Casner Cc: J.Crowcroft@cs.ucl.ac.uk, st@ibminet.awdpa.ibm.com, rem-conf@es.net, END2END-INTEREST@ISI.EDU Subject: Re: ST-II and RSVP paper In-Reply-To: Your message of "Wed, 22 Sep 93 19:29:52 PDT." <748751392.0.CASNER@XFR.ISI.EDU> Date: Thu, 23 Sep 93 09:13:44 +0200 From: Christian Huitema Steve, I do agree with Jon that trying to handle too many parameters is pointless. In fact, I would probably be happy with exactly one -- throughput -- specially if I can do things like SDRP, i.e. rely on end-to-end protocols for selecting the path. Throughput management is probably the only task we need the routers to perform in real time for us. Christian Huitema From rem-conf-request@es.net Thu Sep 23 03:42:59 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <06353-0@osi-east.es.net>; Thu, 23 Sep 1993 00:42:24 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 23 Sep 1993 08:36:52 +0100 To: Stephen Casner cc: J.Crowcroft@cs.ucl.ac.uk, st@ibminet.awdpa.ibm.com, rem-conf@es.net, END2END-INTEREST@ISI.EDU Subject: Re: ST-II and RSVP paper In-reply-to: Your message of "Wed, 22 Sep 93 19:29:52 PDT." <748751392.0.CASNER@XFR.ISI.EDU> Date: Thu, 23 Sep 93 08:36:47 +0100 From: Jon Crowcroft >> personally, i believe, the set of [flowspec] parameters ST had in >> were TOO MANY to experiement with - its too large a search space to >> play with... similarly with all the old RACE QoS work! > >The initial ST-II flowspec had 14 parameters, of which two were really >return values, not parameters. In Craig Partridge's grand reduction >of parameters for the flowspec in RFC 1363, there are 10 parameters, >which doesn't sound so different to me. sure, but i was talkign about a further reduction, not just craig's: the work in some of the ATM community on call admission and policing says that given more than a single parameter exchanged between subscriber and provider (i.e. host & 1st hop router:-) you have an undecidable problem for bot hthe net and the user, whereas if you let the user use their own eqaution for equivalent bandwidth, and simply presend them with a charging (or loss or delay variance prbability) for each effective bandwidth they can choose on a scale, you have the necessar and sufficient exchange of info to optimise... see Frank Kelly's paper in operations research letters, and the work cited there, e.g. elwalid&mitra, ieee/acm trans on networking 1, gibbens&hunt in queueing systems 9, 17-28 or hui in ieee JSAC, 6 p 1598-1608, or kelly, queuing sys 9, pp 5-16 >I'm not claiming that the ST flowspec had the right set of parameters; >it was our first pass and was intended to be changed. The ST spec >states "the FlowSpec will need to be revised as experience is gained". but i think it is hard to experiement with a system that is too complex (that is my bias, but i think you want a system with most things constant, and 1 or a small number of variables, other wise we cannot verify each others work!) cheers jon From rem-conf-request@es.net Thu Sep 23 05:08:17 1993 Received: from research.att.com by osi-east.es.net via ESnet SMTP service id <06496-0@osi-east.es.net>; Thu, 23 Sep 1993 01:55:07 +0000 From: kanakia@research.att.com Date: Thu, 23 Sep 93 04:52:56 EDT To: rem-conf@es.net Jon and Steve, >> personally, i believe, the set of [flowspec] parameters ST had in >> were TOO MANY to experiement with - its too large a search space to >> play with... similarly with all the old RACE QoS work! > >The initial ST-II flowspec had 14 parameters, of which two were really >return values, not parameters. In Craig Partridge's grand reduction >of parameters for the flowspec in RFC 1363, there are 10 parameters, >which doesn't sound so different to me. >>>sure, but i was talkign about a further reduction, not just craig's: May be it is time to re-visit the notion of "flow-spec" itself. As has been pointed out obliquely in the paper by us at SIGCOMM'93 and more directly in private conversations with Craig and others, it is hard to find appropriate flow-spec parameters for a real-time video stream. Real-time nature precludes a-priori knowledge of parameters such as peak, average or minimum bandwidths or equivalent bandwidths. To my knowledge, none of the cited work on equivalent bandwidth has ever been tried on real typical video traces. The real traces differ from each other quite a bit. It does not seem at the moment easy to categorize sources in narrow bands of parameters. A video displaying baseball game played in a ball park produces quite a different trace than the scene that shows sun setting over an ocean. Thus, frequently the choice of flow-spec parameters, either one or many, will be ad-hoc. Ad-hocness in itself is not a problem but it does affect the efficiency in using network resources. If you read that as cost changes with the choice of parameters and the nature of the source, one would understand why there is hesitancy in providing this knob to users all of whom may not be sophisticated. In one of our experiments, we found that the statstical mux'ing gain obtained in running real video-sources through leaky bucket depend heavily on the choice for leaky-bucket parameters, and there was no easy a-priori choice available for these parameters. The mux gain varied as much as 1.4 to 10 depending on how accurate the guess was. Moreover, parameters such as BER or delay distribution related parameters seem to have a complex effect on the perceptual quality of pictures seen. Thus, it seems to me that the discussion of why and what use is each flow-spec parameter should precede the discussion of transport protocols mechansims to exchange flow-spec parameters. >>I'm not claiming that the ST flowspec had the right set of parameters; >>it was our first pass and was intended to be changed. The ST spec >>states "the FlowSpec will need to be revised as experience is gained". >but i think it is hard to experiement with a system that is too >complex (that is my bias, but i think you want a system with most >things constant, and 1 or a small number of variables, other wise we >cannot verify each others work!) alternative, that I think jon may even support based on his work with Ian on feedbacks, would be to specify minimum bandwidths required for good perceptual quality and have source-based adaptive mehcanisms with feedback from network to ensure that everybody gets the "best-possible" quality in video transmission. Hemant Kanakia From rem-conf-request@es.net Thu Sep 23 05:33:47 1993 Received: from mitsou.inria.fr by osi-east.es.net via ESnet SMTP service id <06582-0@osi-east.es.net>; Thu, 23 Sep 1993 02:20:42 +0000 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA13476; Thu, 23 Sep 1993 11:22:33 +0200 Message-Id: <199309230922.AA13476@mitsou.inria.fr> To: Stephen Casner Cc: rem-conf@es.net Subject: RTP, conferences, ports and flow-ID Date: Thu, 23 Sep 93 11:22:32 +0200 From: Christian Huitema Steve, In the new RTP spec, one reads that "a conference" is identified by a group address and a unique port, while different medias use different flow-ids. This is, IMHO, silly. Most of our implementations are based on UDP sockets, which demux based on port numer. Using same port for audio and video obliges the audio driver to also process the video packets.. I would like some text explaining that in the common case we have different ports for control, audio, video, white board, etc. In fact, I would like the whole concept of flow-id removed from the spec -- if one process need to generate several flows, it can always use several source ports! Maybe the spec should concentrate on basic transport functions, and only list transport orientated parameters (QOS) + provide hooks for "session controls" defined elsewhere (mmusic). Christian Huitema From rem-conf-request@es.net Thu Sep 23 08:38:26 1993 Received: from ninet.research.att.com by osi-east.es.net via ESnet SMTP service id <07058-0@osi-east.es.net>; Thu, 23 Sep 1993 05:13:15 +0000 Received: by research.att.com; Thu Sep 23 08:13 EDT 1993 Date: Thu, 23 Sep 93 08:12:12 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: Christian.Huitema@sophia.inria.fr Subject: Re: RTP, conferences, ports and flow-ID Cc: rem-conf@es.net > Steve, Christian, I guess you missed the rem-conf discussion about assigned port numbers a couple of weeks ago. > > In the new RTP spec, one reads that "a conference" is identified by a group > address and a unique port, while different medias use different flow-ids. This > is, IMHO, silly. Most of our implementations are based on UDP sockets, which > demux based on port numer. Using same port for audio and video obliges the > audio driver to also process the video packets.. That's only true if you cannot bind to a multicast address. (SunOS and Irix kernels equipped with the current version of multicast have handled multicast group binding for quite a while). It's a tradeoff: a common port has advantages (accounting/traffic statistics, less likelihood that the port on a given system will already have been taken by some other application when I want to join a conference, fire walls, ...); it does require the per-multicast-group binding. In my opinion, that should actually be part of host requirements, as it simplifies a whole range of issues, in particular once we send different quality video streams to different multicast groups to allow receivers to pick the most appropriate one. > > I would like some text explaining that in the common case we have different > ports for control, audio, video, white board, etc. In fact, I would like the > whole concept of flow-id removed from the spec -- if one process need to > generate several flows, it can always use several source ports! I assume you are talking about the channel id, as it is called in the latest spec. (The name 'flow' was deemed to be taken already, with a slightly different, if related meaning). There are cases where, say, audio and video should be in the same packet. The channel-id also simplifies RTP over IP(ng) and RTP over AAL5. If you don't need the channel id, you don't have to use it. Just set it to zero. It doesn't seem to hurt any (besides having wasted six bits). > > Maybe the spec should concentrate on basic transport functions, and only list > transport orientated parameters (QOS) + provide hooks for "session controls" > defined elsewhere (mmusic). We (at least I) consciously stayed out of the QoS business (at least in terms of specifying needed parameters), since that's very much an open topic (see recent set of messages by Hemant, Steve and yourself). RTCP is separate and can be severed if an application does not need it. mmusic is concerned with more tightly controlled conferences and, from all I can tell, will cover a different part of the spectrum. Thus, waiting for that work to emerge (at least another year, in my estimation, if the much simpler RTP spec is any indication) seems counterproductive. > > Christian Huitema > From rem-conf-request@es.net Thu Sep 23 11:53:37 1993 Received: from zephyr.isi.edu by osi-east.es.net via ESnet SMTP service id <08182-0@osi-east.es.net>; Thu, 23 Sep 1993 08:28:28 +0000 Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Thu, 23 Sep 1993 08:26:58 -0700 Date: Thu, 23 Sep 1993 08:26:58 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199309231526.AA24964@zephyr.isi.edu> To: CASNER@ISI.EDU, Christian.Huitema@sophia.inria.fr Subject: Re: ST-II and RSVP paper Cc: J.Crowcroft@cs.ucl.ac.uk, st@ibminet.awdpa.ibm.com, rem-conf@es.net, END2END-INTEREST@ISI.EDU *> *> Steve, *> *> I do agree with Jon that trying to handle too many parameters is pointless. In *> fact, I would probably be happy with exactly one -- throughput -- specially if *> I can do things like SDRP, i.e. rely on end-to-end protocols for selecting the *> path. Throughput management is probably the only task we need the routers to *> perform in real time for us. *> *> Christian Huitema *> Christian, Tuesday evening of the HOuston meeting, Dave Clark and I will be giving a BOF on precisely this topic... what should the new service model for the Internet be? I hope you will attend. Bob _________________________________________________________________________ Realtime Packet Forwarding and Admission Control BOF (realtime) Tuesday evening 2 November 1993 @ 1930-2200 BOF cochairs: Dave Clark, MIT & Bob Braden, USC/ISI Area: Transport Summary: The demand for multimedia communication and the success of IETF audio/videocasts will soon create an urgent requirement for resource reservation and control in the Internet. From an architectural viewpoint, this represents a new Internet service model. Such a service model should include, in an integrated fashion, both realtime and link-sharing services along with the traditional best-effort datagram services. Research in DARTnet has developed (a) an integrated service model for the Internet, and (b) a particular set of mechanisms to realize this model. To provide end-to-end service suitable for realtime applications, the routers must all implement the same service model, although there may be alternative mechanisms. We therefore propose that the service model be standardized. This BOF will describe the service model and the realization, and suggest the service model as a candidate for Internet standardization. From rem-conf-request@es.net Thu Sep 23 11:56:06 1993 Received: from wugate.wustl.edu by osi-east.es.net via ESnet SMTP service id <08451-0@osi-east.es.net>; Thu, 23 Sep 1993 08:55:29 +0000 Received: by wugate.wustl.edu (5.65c+/WUSTL-0.3) with SMTP id AA07987; Thu, 23 Sep 1993 10:54:34 -0500 Received: by flora.wuccrc (4.1/SMI-4.1) id AA25209; Thu, 23 Sep 93 10:53:55 CDT Message-Id: <9309231553.AA25209@flora.wuccrc> To: braden@isi.edu (Bob Braden) Cc: rem-conf@es.net, END2END-INTEREST@isi.edu Subject: Re: ST-II and RSVP paper In-Reply-To: Your message of Thu, 23 Sep 1993 08:26:58 -0700. <199309231526.AA24964@zephyr.isi.edu> Date: Thu, 23 Sep 1993 10:53:48 -0500 From: Gurudatta Parulkar Bob: The proposed BOF is a great idea. Is it open to everybody? Assuming I come to IETF, I would like to participate in your BOF. You mention that for DARTnet an integrated service model has been developed. Which model are you talking about? Could you please point to a RFC or papers? You also mention service model should include, in an integrated fashion, both realtime and link-sharing services along with the traditional best-effort datagram services. Research in DARTnet has developed Are you talking about three kinds of services: real time, link sharing, and datagram or two? -guru parulkar ---------------- Realtime Packet Forwarding and Admission Control BOF (realtime) Tuesday evening 2 November 1993 @ 1930-2200 BOF cochairs: Dave Clark, MIT & Bob Braden, USC/ISI Area: Transport Summary: The demand for multimedia communication and the success of IETF audio/videocasts will soon create an urgent requirement for resource reservation and control in the Internet. From an architectural viewpoint, this represents a new Internet service model. Such a service model should include, in an integrated fashion, both realtime and link-sharing services along with the traditional best-effort datagram services. Research in DARTnet has developed (a) an integrated service model for the Internet, and (b) a particular set of mechanisms to realize this model. To provide end-to-end service suitable for realtime applications, the routers must all implement the same service model, although there may be alternative mechanisms. We therefore propose that the service model be standardized. This BOF will describe the service model and the realization, and suggest the service model as a candidate for Internet standardization. From rem-conf-request@es.net Thu Sep 23 14:50:04 1993 Received: from zephyr.isi.edu by osi-east.es.net via ESnet SMTP service id <08992-0@osi-east.es.net>; Thu, 23 Sep 1993 09:47:21 +0000 Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Thu, 23 Sep 1993 09:42:32 -0700 Date: Thu, 23 Sep 1993 09:42:32 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199309231642.AA26436@zephyr.isi.edu> To: braden@ISI.EDU, guru@flora.wustl.edu Subject: Re: ST-II and RSVP paper Cc: rem-conf@es.net, END2END-INTEREST@ISI.EDU *> From guru@flora.wustl.edu Thu Sep 23 08:55:33 1993 *> To: braden@ISI.EDU (Bob Braden) *> Cc: rem-conf@es.net, END2END-INTEREST@ISI.EDU *> Subject: Re: ST-II and RSVP paper *> In-Reply-To: Your message of Thu, 23 Sep 1993 08:26:58 -0700. *> <199309231526.AA24964@zephyr.isi.edu> *> Date: Thu, 23 Sep 1993 10:53:48 -0500 *> From: Gurudatta Parulkar *> Content-Length: 1915 *> X-Lines: 49 *> *> *> Bob: *> *> The proposed BOF is a great idea. Is it open to everybody? Assuming I Guru, Yes, of course! Openness if the name of the game in IETF. *> come to IETF, I would like to participate in your BOF. *> *> You mention that for DARTnet an integrated service model has been *> developed. Which model are you talking about? Could you please point *> to a RFC or papers? Attached is a msg that was sent to one of these lists recently, announcing the most recent paper. The ealier paper by Clark, Shenker, and Zhang was in SIGCOMM '92. *> *> You also mention *> *> service model should include, in an integrated fashion, both *> realtime and link-sharing services along with the traditional *> best-effort datagram services. Research in DARTnet has developed *> *> Are you talking about three kinds of services: real time, link *> sharing, and datagram or two? *> There are two services to the user -- realtime and BE -- and one service to network providers -- controlled link sharing. Bob *> -guru parulkar *> ----- Begin Included Message ----- >From shenker@parc.xerox.com Mon Aug 30 04:01:44 1993 From: Scott Shenker To: end2end-interest@ISI.EDU Subject: paper available Cc: shenker@parc.xerox.com Date: Fri, 27 Aug 1993 08:43:45 PDT Content-Length: 1579 X-Lines: 36 I would like to announce the availability via anonymous ftp of the following paper: parcftp.xerox.com:/transient/service-model.ps A Scheduling Service Model and a Scheduling Architecture for an Integrated Services Packet Network Scott Shenker, David D. Clark, and Lixia Zhang Abstract: Integrated Services Packet Networks (ISPN) are designed to integrate the network service requirements of a wide variety of computer-based applications. Some of these services are delivered primarily through the packet scheduling algorithms used in the network switches. This paper addresses two questions related to these scheduling algorithms. The first question is: what scheduling services should an ISPN offer? In answer, we propose a scheduling service model for ISPN's which is based on our projections about future application and institutional service requirements. Our service model includes both a delay-related component designed to meet the ergonomic requirements of individual applications, and also a hierarchical link-sharing component designed to meet the economic needs of resource sharing between different entities. The second question we address is: what implications does this service model have for the packet scheduling algorithms? We answer this question by constructing a scheduling architecture, and then argue that any scheduling algorithm capable of supporting our scheduling service model must conform to this architecture. The scheduling architecture is derived from the natural precedence ordering of the service model's various scheduling goals. ----- End Included Message ----- From rem-conf-request@es.net Thu Sep 23 17:48:36 1993 Received: from research.att.com by osi-east.es.net via ESnet SMTP service id <19968-0@osi-east.es.net>; Thu, 23 Sep 1993 14:31:05 +0000 From: kanakia@research.att.com Date: Thu, 23 Sep 93 17:30:44 EDT To: rem-conf@es.net Bob, I am happy to clarify furthur. My msg: *> May be it is time to re-visit the notion of "flow-spec" *> itself. As has been pointed out obliquely in the paper by us *> at SIGCOMM'93 and more directly in private conversations with Craig and *> others, it is hard to find appropriate flow-spec parameters for a *> real-time video stream. Real-time nature precludes a-priori knowledge *> of parameters such as peak, average or minimum bandwidths or equivalent *> bandwidths. To my knowledge, none of the cited work on equivalent *> bandwidth has ever been tried on real typical video traces. The real *> traces differ from each other quite a bit. It does not seem at the *> moment easy to categorize sources in narrow bands of parameters. Your msg: >>Hamant, >>I don't think we ever said that a flowspec has to define a NARROW band >>of parameters. You stopped parsing the message too early. here is the next sentence reproduced again below. *>Thus, frequently the choice of flow-spec parameters, either one or many, *>will be ad-hoc. Ad-hocness in itself is not a problem but it does *>affect the efficiency in using network resources. It means that defining flowspecs with broad range of parameters is not quite useful for resource reservation purposes. proof? read the part about the stat mux gain experimental results I mentioned. Onwards to the next point. >>For example, in CSZ Predicted Service the flowspec >>defines a very BROAD band delay. The flowspec is still useful. Nowhere in that paper or elsewhere one has quantified the gain of using predicted service. May be showing some concrete measures such as how many more voice circuits were possible because one implemented predictive service with VAT would convert everybody to believe that it is worth implementing predicted service model on a large scale. Aren't there systems on Internet currently that has audio conference capability and does not use adpative stuff that VAT uses? May be that can be used for comparison. Until that happens it seems pointless to talk about its needs for having flow-specs. Your Msg: >>The system effectiveness then depends upon the sensitivity of the >>pricing model. If small changes in flowspecs produce large changes in >>cost, it is not going to work. and now it is my turn to say I completely fail to follow your reasoning at this point. I had said in the msg that it does produce quite different stat mux gain within network depending on the accuracy of flow spec parameters (these were LB param in our experiments.) If you want to read about these results in detial, I can point you to paper(s). Alternatively, may be you should point me to papers or works which suggests that costs are not that sensitive to accuracy of flow-spec parameters. and one's pricing model I hope reflects the costs. My Msg: *> *> Thus, it seems to me that the discussion of why and what use is each *> flow-spec parameter should precede the discussion of transport *> protocols mechansims to exchange flow-spec parameters. *> Your Msg: >>Why can't >>the transport protocols be designed independently of the contents >>of the flowspec?? One can and does design transport protocols independently of the contents of the flowspec. But, if you decide not to need flow-specs or very different flow-specs, would not that change your protocols? Of course transport protocols do change after being designed but as you have found out with each proposed change in TCP, that it gets harder to do so. Cheers.. Hemant ** Open-ness combined with curiosity and scientific enquiry is indeed my motto :-):-) From rem-conf-request@es.net Thu Sep 23 20:38:20 1993 Received: from usc.edu by osi-east.es.net via ESnet SMTP service id <02687-0@osi-east.es.net>; Thu, 23 Sep 1993 17:37:44 +0000 Received: from topanga.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA15211; Thu, 23 Sep 93 17:37:40 PDT Received: by topanga.usc.edu (4.1/SMI-4.1+ucs-3.6) id AA01064; Thu, 23 Sep 93 17:39:05 PDT Message-Id: <9309240039.AA01064@topanga.usc.edu> From: Sugih Jamin Date: Thu, 23 Sep 1993 17:39:05 -0700 Sender: jamin@parc.xerox.com Reply-To: jamin@parc.xerox.com Phone: +1 415 812 4834 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rem-conf@es.net Hi, > Nowhere in that paper or elsewhere one has quantified the gain of using > predicted service. May be showing some concrete measures such as how many > more voice circuits were possible because one implemented predictive > service with VAT would convert ody to believe that it is > worth implementing predicted service model on a large scale. In our admission control extended abstract presented at the 3rd Int'l Workshop on Network and OS Support for Digital Audio and Video, we reported results from a simple simulation scenario where predictive service is shown to increase network utilization by order of magnitude. The abstract is ftp-able from caldera.usc.edu (128.125.51.17) in pub/jamin/admctl.ps.Z. -- sugih From rem-conf-request@es.net Fri Sep 24 00:08:30 1993 Received: from tenet.ICSI.Berkeley.EDU by osi-east.es.net via ESnet SMTP service id <04713-0@osi-east.es.net>; Thu, 23 Sep 1993 21:03:33 +0000 Received: by tenet.ICSI.Berkeley.EDU (5.63/1.42) id AA02126; Thu, 23 Sep 93 21:02:42 -0700 Date: Thu, 23 Sep 93 21:02:42 -0700 From: hzhang@tenet.ICSI.Berkeley.EDU (Hui Zhang) Message-Id: <9309240402.AA02126@tenet.ICSI.Berkeley.EDU> To: jamin@parc.xerox.com Cc: end2end-interest@ISI.EDU, rem-conf@es.net > From jamin@catarina.usc.edu Thu Sep 23 15:37:53 1993 > To: kanakia@research.att.com > Cc: end2end-interest@ISI.EDU > Status: R > > Hi, > > > Nowhere in that paper or elsewhere one has quantified the gain of using > > predicted service. May be showing some concrete measures such as how many > > more voice circuits were possible because one implemented predictive > > service with VAT would convert ody to believe that it is > > worth implementing predicted service model on a large scale. > > In our admission control extended abstract presented at the 3rd Int'l Workshop > on Network and OS Support for Digital Audio and Video, we reported results > from a simple simulation scenario where predictive service is shown to > increase network utilization by order of magnitude. The abstract is ftp-able > from caldera.usc.edu (128.125.51.17) in pub/jamin/admctl.ps.Z. > > -- > sugih Sugih, In the paper, the peak rate of the source is 160 kbps (160 packets/sec and 1000 kb/packet). However, the reserved rate for guaranteed service is 1500 kbps, which is an order of magnitude higher than the peak rate. This results in the poor utilization in the case of guaranteed performance service. Could you please explain how the 1500 kbps is derived ? Also, why is the token bucket chosen with r = 120 tokens/sec and b = 30 tokens /sec? How much does the result depend on the choices of r and b? A larger b results in a high delay bound in the case of WFQ. What if r is chosen to be 160 tokens/sec (peak rate), and b is chosen to be 1? Thanks. Hui From rem-conf-request@es.net Fri Sep 24 05:50:57 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <06533-0@osi-east.es.net>; Fri, 24 Sep 1993 02:42:34 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 24 Sep 1993 10:16:47 +0100 To: CASNER@ISI.EDU, Christian.Huitema@sophia.inria.fr, J.Crowcroft@cs.ucl.ac.uk, st@ibminet.awdpa.ibm.com, rem-conf@es.net, END2END-INTEREST@ISI.EDU Subject: Re: ST-II and RSVP paper In-reply-to: Your message of "Thu, 23 Sep 93 08:26:58 PDT." <199309231526.AA24964@zephyr.isi.edu> Date: Fri, 24 Sep 93 10:16:45 +0100 From: Jon Crowcroft basically, my concern was that we have too many efforts towards internet standardising - (hence the wide to: line) the ibm et al berkom & isi/bbn dsi etc work on ST _is_ extremeley valuble research, but unless they intend to propose ST-II as IPng (:-) i don't see why the IETF need another wg to dilute the efforts in place already, except maybe to act as a focus tfor reporting results to others... or are the ST people claiming it is _more_ than a research vehicle? or are they going to propose a standard purely for research purposes (not a bad idea!)? cheers jon From rem-conf-request@es.net Fri Sep 24 12:24:06 1993 Received: from ibminet.awdpa.ibm.com by osi-east.es.net via ESnet SMTP service id <09417-0@osi-east.es.net>; Fri, 24 Sep 1993 09:16:17 +0000 Received: by ibminet.awdpa.ibm.com (5.61/1.15) id AA23803; Fri, 24 Sep 93 09:16:58 -0700 Received: from muddy.awdpa.ibm.com by ibmpa.awdpa.ibm.com (5.65b(em1)/2.06) id AA09964; Fri, 24 Sep 93 09:13:35 -0700 Received: by muddy.awdpa.ibm.com (AIX 3.2/UCB 5.64/4.10) id AA25817; Fri, 24 Sep 1993 09:08:29 -0700 From: steve@ibmpa.awdpa.ibm.com (Steve DeJarnett) Message-Id: <9309241608.AA25817@muddy.awdpa.ibm.com> Subject: Re: ST-II and RSVP paper To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Fri, 24 Sep 1993 09:08:28 -0800 (PDT) Cc: CASNER@ISI.EDU, Christian.Huitema@sophia.inria.fr, J.Crowcroft@cs.ucl.ac.uk, st@ibminet.awdpa.ibm.com, rem-conf@es.net, END2END-INTEREST@ISI.EDU In-Reply-To: <9309240920.AA20949@ibminet.awdpa.ibm.com> from "Jon Crowcroft" at Sep 24, 93 10:16:45 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2607 Jon Crowcroft wrote: >basically, my concern was that we have too many efforts towards >internet standardising - (hence the wide to: line) This is a concern that was brought up at the last IETF (when we had the ST-II Futures BOF). We (the attendees of said BOF) agreed not to push ST as a standards track protocol at this point. If sometime in the future it makes sense to have ST be on the standards track then we can all have that discussion then. >the ibm et al berkom & isi/bbn dsi etc work on ST _is_ extremeley valuble >research, but unless they intend to propose ST-II as IPng (:-) i don't see why >the IETF need another wg to dilute the efforts in place already, >except maybe to act as a focus tfor reporting results to others... I don't think we'll attempt to claim to solve all of the world's problems, so no, ST is probably not a good candidate for IPng. :-) One of the main reasons for having the WG (cited in the charter) is to fix up the ST-II spec to allow interested parties to build interoperable implementations without having to have the equivalent of "bakeoffs" to ensure compatibility (certainly they're useful and a good way to test the error handling, etc. but it's good to have an idea that you can interoperate before you start that). The fact is that companies are building products based around ST-II today (IBM, BBN, and the BERKOM participants being the most visible). We'd all like to have a common _implementable_ spec to work with. RFC 1190 is good but lacks some key pieces (such as state transition diagrams) that give you confidence that the implementation you're building will work with anyone else's. We'd simply like to clean up the spec. If people want to standardize it later, that's something to address at that time. Not now. All the current charter says is that we're working on this to help solve some immediate problems that we've seen and that the result will be an Experimental RFC. >or are the ST people claiming it is _more_ than a research vehicle? > >or are they going to propose a standard purely for research purposes >(not a bad idea!)? I'd say it's purpose is actually two-fold. Get the specification into shape for companies building products around it (so we can at least say that our RFC XXXX compatible implementation should work with vendor YYYY's RFC XXXX compatible implementation), and as an added side-benefit, the groups doing research in this area can draw on a number of implementations to compare/ contrast the behavior of ST-based systems and (insert your favorite protocol(s) here). Clear as mud?? Steve From rem-conf-request@es.net Fri Sep 24 12:26:48 1993 Received: from ORACLE.BBN.COM by osi-east.es.net via ESnet SMTP service id <09446-0@osi-east.es.net>; Fri, 24 Sep 1993 09:18:12 +0000 Received: from WOOLIE.BBN.COM by ORACLE.BBN.COM id aa18292; 24 Sep 93 11:48 EDT To: Jon Crowcroft cc: CASNER@isi.edu, Christian.Huitema@sophia.inria.fr, st@ibminet.awdpa.ibm.com, rem-conf@es.net, END2END-INTEREST@isi.edu Subject: Re: ST-II and RSVP paper In-reply-to: Your message of "Fri, 24 Sep 1993 10:16:45 BST." Date: Fri, 24 Sep 1993 12:07:08 -0400 From: Lou Berger Jon, My (I'm speaking for myself, not BBN) interest is to have mechanisms for unicast and multicast resource management. For IP, there currently exists support for multicast, but not resource management. There are several projects underway to provide IP with resource management but none are yet supporting operational use. (Where users are people who expect a service and get mad when the service is not provided.) This leaves (at least) me with the problem of how to support requirements for resource management today. From my perspective, the IP resource management efforts are still not ready for operational use. It's not that I think they won't mature to that point, I just don't think they are there yet. On the other hand, I do believe that ST can be used today to satisfy a certain set of requirements. ST has been in existence for a some time and has been refined through quite a bit of implementation experience. This doesn't mean I think ST is the 'right' long term solution. It does have its real technical problems and limitations. But it can, and is, being used to provide service today. I see that ST fills the gap until the next generation protocols (e.g. RSVP) that solve the problems that ST solves, without its failings, are available. For me, it's not ST vs RSVP, it's ST now and a replacement when its available. The new ST working group has a limited focus. Its goal is to produce a revised and simplified specification, not an enhanced protocol. The current RFC has a number of holes and leaves a couple of areas too open for separate implementations to be easily interoperable. The working group will be focused on these issues. I don't think that an ST working group conflicts with the existence of other groups looking at alternative resource management mechanisms. The ST working group has a different focus than other (to be formed) working groups. It is focused on clarification and interoperability, not protocol development. Lou Berger (This message is my opinion, not my employer's) From rem-conf-request@es.net Fri Sep 24 12:36:41 1993 Received: from picard.cmf.nrl.navy.mil by osi-east.es.net via ESnet SMTP service id <09645-0@osi-east.es.net>; Fri, 24 Sep 1993 09:28:49 +0000 Received: from herman.cmf.nrl.navy.mil by picard (4.1/SMI-4.1) id AA22166; Fri, 24 Sep 93 12:28:40 EDT Received: from localhost by herman.cmf.nrl.navy.mil (4.1/client-1.3) id AA13037; Fri, 24 Sep 93 12:28:39 EDT Message-Id: <9309241628.AA13037@herman.cmf.nrl.navy.mil> To: casner@isi.edu Subject: Usage of the Reverse-Path option (section 5.3) Cc: rem-conf@es.net Date: Fri, 24 Sep 1993 12:28:37 -0400 From: William C Fenner After looking over draft-ietf-avt-rtp-03.ps, I am a little unclear on what format packets sent using the Reverse-Path option should have. I am thinking of using the Reverse-Path option to request JPEG Quantization and Huffman Coding tables; my idea was that these tables would be multicast once at the beginning of the conference, and those who missed them could request them via a unicast Reverse-Path packet. However, it's not clear how to instrument the request. I have come up with three possible scenarios: 1. Declare a new format, of type "jpeg-request" and use the data portion of the packet to make my request. 2. Create a new option, and have there be no actual data in the packet. 3. Use the "FMT" RTCP option, and insert my request in the format-dependent section. 1 and 2 are not very desirable, since they use up numbers in the limited format or option numbering space. However, it's not very clear what the FMT RTCP option is actually supposed to be used for, and if my intended use is not usurping its actual purpose and may cause problems later. Can anyone shed some light? It seems as though requests like this would be a common use of the Reverse-Path packet, so I think it would be a good idea to get this issue clarified in the document before RTP achieves standard status. Thanks, Bill From rem-conf-request@es.net Fri Sep 24 12:59:50 1993 Received: from thdsun.EPM.ORNL.GOV by osi-east.es.net via ESnet SMTP service id <10349-0@osi-east.es.net>; Fri, 24 Sep 1993 09:51:41 +0000 Received: by thdsun.EPM.ORNL.GOV (4.1/1.34) id AA20421; Fri, 24 Sep 93 12:51:38 EDT Date: Fri, 24 Sep 93 12:51:38 EDT From: dunigan@thdsun.EPM.ORNL.GOV (Tom Dunigan 576-2522) Message-Id: <9309241651.AA20421@thdsun.EPM.ORNL.GOV> To: rem-conf@es.net Subject: net problems with IPmulticast, mrouted, SunOS4.1.3, sparc10 Since adding IPmulticast to the kernel and running mrouted on our sparc10/41 with SunOS4.1.3, we have in the past few days experienced times when the Sun will not ping "some" local Ether hosts. Arp entries look OK. Those hosts cannot ping our mrouted host either. Some NFS clients to the mrouted machine also experience "outages". After some number of minutes, service often returns to normal. (or a reboot fixes it ....). I see nothing overly peculiar in netstat -s ... but maybe there is something else I need to look at. Anyone else had similar experiences, there could be something else going on, but ipmulticast/mrouted are the leading suspects at the moment. thanks tom From rem-conf-request@es.net Fri Sep 24 13:03:49 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <10694-0@osi-east.es.net>; Fri, 24 Sep 1993 10:01:11 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 24 Sep 1993 18:00:32 +0100 To: steve@ibmpa.awdpa.ibm.com (Steve DeJarnett) cc: st@ibminet.awdpa.ibm.com, rem-conf@es.net, END2END-INTEREST@ISI.EDU Subject: Re: ST-II and RSVP paper In-reply-to: Your message of "Fri, 24 Sep 93 09:08:28 -0900." <9309241608.AA25817@muddy.awdpa.ibm.com> Date: Fri, 24 Sep 93 18:00:30 +0100 From: Jon Crowcroft > I don't think we'll attempt to claim to solve all of the world's >problems, so no, ST is probably not a good candidate for IPng. :-) ok, sipp, of course does solve all the worldsproblems:-) clnp, on the other hand, causessome new ones, which it then also solves... >We'd simply like to clean up the spec. If people want to standardize it later, fine - vry sensible. > I'd say it's purpose is actually two-fold. Get the specification into >shape for companies building products around it (so we can at least say that >our RFC XXXX compatible implementation should work with vendor YYYY's RFC XXXX >compatible implementation), and as an added side-benefit, the groups doing ok...thanbks for the detailed answer... jon From rem-conf-request@es.net Fri Sep 24 13:08:40 1993 Received: from alpha.Xerox.COM by osi-east.es.net via ESnet SMTP service id <10690-0@osi-east.es.net>; Fri, 24 Sep 1993 10:00:38 +0000 Received: from kearsarge.parc.xerox.com ([13.2.116.189]) by alpha.xerox.com with SMTP id <11911(9)>; Fri, 24 Sep 1993 09:58:20 PDT Received: by kearsarge.parc.xerox.com id <2703>; Fri, 24 Sep 1993 09:58:13 -0700 Sender: Sugih Jamin From: jamin@parc.xerox.com (Sugih Jamin) Date: Fri, 24 Sep 1993 09:57:59 PDT Phone: +1 415 812 4834 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: hzhang@tenet.icsi.berkeley.edu (Hui Zhang) Subject: admission control Cc: end2end-interest@isi.edu, rem-conf@es.net Message-Id: <93Sep24.095813pdt.2703@kearsarge.parc.xerox.com> --- Included message from hzhang@tenet.icsi.berkeley.edu (Sep 23) > >> From jamin@catarina.usc.edu Thu Sep 23 15:37:53 1993 >> >> In our admission control extended abstract presented at the 3rd Int'l >> Workshop on Network and OS Support for Digital Audio and Video, we >> reported results from a simple simulation scenario where predictive >> service is shown to increase network utilization by order of magnitude. >> The abstract is ftp-able from caldera.usc.edu (128.125.51.17) in >> pub/jamin/admctl.ps.Z. > > Sugih, > > In the paper, the peak rate of the source is 160 kbps (160 packets/sec and > 1000 kb/packet). However, the reserved rate for guaranteed service is > 1500 kbps, which is an order of magnitude higher than the peak rate. This > results in the poor utilization in the case of guaranteed performance service. > Could you please explain how the 1500 kbps is derived ? The delay experienced (d-hat) is bucket depth (b) over reserved rate (r). If you reserved guaranteed flow with r = 160 Kbps, for b = 30 Kbits, your d-hat will be 187 ms. Thus, the abstract says, "For a guaranteed flow to obtain the same delay bound of 20 ms, it would have to request a reserved rate of 1500 Kpbs." > Also, why is the token bucket chosen with r = 120 tokens/sec and > b = 30 tokens /sec? How much does the result depend on the choices > of r and b? A larger b results in a high delay bound in the > case of WFQ. What if r is chosen to be 160 tokens/sec (peak rate), and > b is chosen to be 1? If b is 1, then your stream cannot burst at all. As we said in the abstract, the simulation scenario is a very simple one. We're currently conducting further studies into simulations with more diverse sources, etc. -- sugih From rem-conf-request@es.net Fri Sep 24 13:35:54 1993 Received: from tenet.ICSI.Berkeley.EDU by osi-east.es.net via ESnet SMTP service id <11842-0@osi-east.es.net>; Fri, 24 Sep 1993 10:28:16 +0000 Received: by tenet.ICSI.Berkeley.EDU (5.63/1.42) id AA09306; Fri, 24 Sep 93 10:27:28 -0700 Date: Fri, 24 Sep 93 10:27:28 -0700 From: hzhang@tenet.ICSI.Berkeley.EDU (Hui Zhang) Message-Id: <9309241727.AA09306@tenet.ICSI.Berkeley.EDU> To: jamin@parc.xerox.com Subject: Re: admission control Cc: end2end-interest@isi.edu, rem-conf@es.net > From jamin@parc.xerox.com Fri Sep 24 10:00:38 1993 >> Also, why is the token bucket chosen with r = 120 tokens/sec and >> b = 30 tokens /sec? How much does the result depend on the choices >> of r and b? A larger b results in a high delay bound in the >> case of WFQ. What if r is chosen to be 160 tokens/sec (peak rate), and > > b is chosen to be 1? > If b is 1, then your stream cannot burst at all. As we said in the abstract, > the simulation scenario is a very simple one. We're currently conducting > further studies into simulations with more diverse sources, etc. Hi Sugih, When you reserve at the peak rate at r = 160 tokens/sec, you only need b to be 1. In this case, d-hat will be 1000bits/160kbps = 6.25 ms. Since the peak-average-rate-ratio ratio is 2, the guarantee performance traffic can get a 6.25 ms delay bound with a link utilization of 50%. I am not suggesting that reserving at peak is the best solution. However, in the particular case, it achieves much better result than the simulated setup in the paper. It seems that the result highly depends on the choices of b and r. And the numbers picked in the paper are not particularly well suited for guaranteed performance service traffic. Hui From rem-conf-request@es.net Fri Sep 24 13:45:57 1993 Received: from jazz.concert.net by osi-east.es.net via ESnet SMTP service id <12047-0@osi-east.es.net>; Fri, 24 Sep 1993 10:38:05 +0000 Received: by jazz.concert.net (5.59/tas-concert/8-12-92) id AA09417; Fri, 24 Sep 93 13:37:57 -0400 From: Fengmin Gong Message-Id: <9309241737.AA09417@jazz.concert.net> Subject: Re: Usage of the Reverse-Path option (section 5.3) To: fenner@herman.cmf.nrl.navy.mil (William C Fenner) Date: Fri, 24 Sep 1993 13:37:56 -0400 (EDT) Cc: casner@isi.edu, rem-conf@es.net In-Reply-To: <9309241628.AA13037@herman.cmf.nrl.navy.mil> from "William C Fenner" at Sep 24, 93 11:28:37 am X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 2202 William C Fenner wrote in a previous message: > >After looking over draft-ietf-avt-rtp-03.ps, I am a little unclear on what >format packets sent using the Reverse-Path option should have. > >I am thinking of using the Reverse-Path option to request JPEG Quantization and >Huffman Coding tables; my idea was that these tables would be multicast once >at the beginning of the conference, and those who missed them could request >them via a unicast Reverse-Path packet. > >However, it's not clear how to instrument the request. I have come up with >three possible scenarios: > >1. Declare a new format, of type "jpeg-request" and use the data portion > of the packet to make my request. >2. Create a new option, and have there be no actual data in the packet. >3. Use the "FMT" RTCP option, and insert my request in the format-dependent > section. > >1 and 2 are not very desirable, since they use up numbers in the limited >format or option numbering space. However, it's not very clear what the >FMT RTCP option is actually supposed to be used for, and if my intended >use is not usurping its actual purpose and may cause problems later. > >Can anyone shed some light? It seems as though requests like this would >be a common use of the Reverse-Path packet, so I think it would be a good >idea to get this issue clarified in the document before RTP achieves >standard status. > I do believe that one of the reverse-path options should be used. The latest RTP draft says: "The format of reverse RTP packets is exactly the same as for regular RTP packets and they can make use of all the options defined in this memorandum, except SSRC, as appropriate. The support for and semantics of particular options are to be specified by a profile." I think the RAD (reverse application data) option in one of the earlier draft is a good one to keep, to be used for things William mentioned and things like request for an Intra-coded frame for H.261 or MPEG. Such things need to be specified in the RTP document but not a profile. For one thing, it will be very confusing if someone just go off and interpret one of the forward options to mean "request for quantization value". Fengmin From rem-conf-request@es.net Fri Sep 24 14:57:42 1993 Received: from alpha.Xerox.COM by osi-east.es.net via ESnet SMTP service id <13645-0@osi-east.es.net>; Fri, 24 Sep 1993 11:50:49 +0000 Received: from kearsarge.parc.xerox.com ([13.2.116.189]) by alpha.xerox.com with SMTP id <11952(6)>; Fri, 24 Sep 1993 11:50:27 PDT Received: by kearsarge.parc.xerox.com id <2703>; Fri, 24 Sep 1993 11:50:23 -0700 Sender: Sugih Jamin From: jamin@parc.xerox.com (Sugih Jamin) Date: Fri, 24 Sep 1993 11:50:12 PDT Phone: +1 415 812 4834 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: hzhang@tenet.icsi.berkeley.edu (Hui Zhang) Subject: Re: admission control Cc: end2end-interest@isi.edu, rem-conf@es.net Message-Id: <93Sep24.115023pdt.2703@kearsarge.parc.xerox.com> --- Included message from hzhang@tenet.icsi.berkeley.edu (Sep 24) > >> If b is 1, then your stream cannot burst at all. As we said in the abstract, >> the simulation scenario is a very simple one. We're currently conducting >> further studies into simulations with more diverse sources, etc. > > When you reserve at the peak rate at r = 160 tokens/sec, you only need > b to be 1. In this case, d-hat will be 1000bits/160kbps = 6.25 ms. Since > the peak-average-rate-ratio ratio is 2, the guarantee performance traffic > can get a 6.25 ms delay bound with a link utilization of 50%. With b = 1 you're assuming that only constant bit rate sources will use guaranteed service? Even then, you only get half the network utilization of network with predictive service (according to the simple simulation). -- sugih From rem-conf-request@es.net Fri Sep 24 15:51:47 1993 Received: from picard.cmf.nrl.navy.mil by osi-east.es.net via ESnet SMTP service id <14770-0@osi-east.es.net>; Fri, 24 Sep 1993 12:51:13 +0000 Received: from herman.cmf.nrl.navy.mil by picard (4.1/SMI-4.1) id AA23689; Fri, 24 Sep 93 15:51:04 EDT From: fenner@cmf.nrl.navy.mil Received: by herman.cmf.nrl.navy.mil (4.1/client-1.3) id AA13566; Fri, 24 Sep 93 15:51:03 EDT Date: Fri, 24 Sep 93 15:51:03 EDT Message-Id: <9309241951.AA13566@herman.cmf.nrl.navy.mil> To: casner@isi.edu, hgs@research.att.com Subject: Specification of JPEG encoding format in encodings document Cc: rem-conf@es.net Although JFIF is already specified, and will work for JPEG videoconferencing, I believe it is a poor choice. A JFIF file is designed to be usable standalone, so it must include the quantization tables and the huffman tables. These are unlikely to change through the conference, and can be reasonably large (a JFIF that I have handy has 607 bytes of tables and 8kbytes of data). There are a couple of alternatives to sending the tables with every frame. For a large proportion of conferences, it would suffice to include a Q-factor, and have a well-known algorithm (tentatively, the one used by the freely available Independent JPEG Group software) to calculate the quantization tables from the Q-factor. This could take as little as one byte per packet of overhead (Or, optionally, could be defined as an option... again, I'm not clear if the RTCP FMT option is the right place for this or not). The Huffman tables could be distributed as below, or the default tables defined in the JPEG standard could be used. Alternately, the tables could be multicast in full at the beginning of the conference (or any time they change), and be requested via a reverse-channel request by any clients that join late. This allows full flexibility in specifying the tables, although I'm not really clear on how important this actually is. The scheme I'm envisioning essentially combines these ideas; it reserves a special Q value to mean "custom tables", and includes a flag as to whether to use the Huffman tables defined in the spec or to use custom tables. I will be doing more work on this after I decide on a fragmentation / reassembly scheme and as our equipment comes back from a demo so I have more than one JPEG video card. I'd be interested in hearing from anyone who has a JPEG video card other than the Parallax XVideo/24, to do interoperability testing. Bill From rem-conf-request@es.net Fri Sep 24 15:55:44 1993 Received: from tenet.ICSI.Berkeley.EDU by osi-east.es.net via ESnet SMTP service id <14732-0@osi-east.es.net>; Fri, 24 Sep 1993 12:49:06 +0000 Received: by tenet.ICSI.Berkeley.EDU (5.63/1.42) id AA11639; Fri, 24 Sep 93 12:48:27 -0700 Date: Fri, 24 Sep 93 12:48:27 -0700 From: hzhang@tenet.ICSI.Berkeley.EDU (Hui Zhang) Message-Id: <9309241948.AA11639@tenet.ICSI.Berkeley.EDU> To: jamin@parc.xerox.com Subject: Re: admission control Cc: end2end-interest@isi.edu, rem-conf@es.net > From jamin@parc.xerox.com Fri Sep 24 11:50:50 1993 > With b = 1 you're assuming that only constant bit rate sources will use > guaranteed service? Even then, you only get half the network utilization > of network with predictive service (according to the simple simulation). > > -- Hi Sugih, b = 1 doesn't imply constant bit rate source, just that the previous example I gave reserved resources at the peak rate. The sources can still be bursty. The point that I was trying to make is that the claim that "predicted service can over-perform guaranteed service by an order of magnitude" is not justified by the example given in the paper. Actually, by picking different parameters with token bucket and delay bounds (without changing the source traffic), guaranteed service may achieve a higher utilization. For example, if you pick r = 160, b = 1, and d = 6.25 ms, guaranteed service can achieve 50% link utilization, how much can predicted service do? Of course, the burstier the traffic is, the poorer the peak-rate allocation strategy would be. Our recent work has shown that even for guaranteed service, peak-rate allocation is not required. Hui From rem-conf-request@es.net Fri Sep 24 16:27:59 1993 Received: from tenet.ICSI.Berkeley.EDU by osi-east.es.net via ESnet SMTP service id <15228-0@osi-east.es.net>; Fri, 24 Sep 1993 13:20:35 +0000 Received: by tenet.ICSI.Berkeley.EDU (5.63/1.42) id AA12239; Fri, 24 Sep 93 13:20:00 -0700 Date: Fri, 24 Sep 93 13:20:00 -0700 From: knightly@tenet.ICSI.Berkeley.EDU (Edward W. Knightly) Message-Id: <9309242020.AA12239@tenet.ICSI.Berkeley.EDU> To: jamin@parc.xerox.com Subject: Re: Admission Cc: end2end-interest@isi.edu, rem-conf@es.net Sugih, I think we need to think of the leaky bucket as a filter and not a source. I believe Hui is correct in noting that if a source generates traffic at (e.g.) peak rate of 160 and average rate of 80, it will pass through the filter (leaky bucket) unaffected (or at most delayed by one token time) if the leaky bucket has r = 160 and b = 1. Therefore, setting b = 1 does not necessarily create a CBR stream at the output of the filter. Ed From rem-conf-request@es.net Fri Sep 24 20:22:35 1993 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <18051-0@osi-east.es.net>; Fri, 24 Sep 1993 17:14:58 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Fri, 24 Sep 1993 17:14:54 -0700 Posted-Date: Fri 24 Sep 93 17:14:08 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Fri, 24 Sep 93 17:14:09 PDT Date: Fri 24 Sep 93 17:14:08 PDT From: Stephen Casner Subject: Re: Usage of the Reverse-Path option (section 5.3) To: fenner@herman.cmf.nrl.navy.mil Cc: rem-conf@es.net Message-Id: <748916048.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9309241628.AA13037@herman.cmf.nrl.navy.mil> Mail-System-Version: William C Fenner: Thanks for pointing out a spot where the RTP draft was unclear. > so I think it would be a good idea to get this issue clarified in > the document before RTP achieves standard status. Please note that what has been requested is entry onto the standards track; there's quite a distance before it may become a standard, even assuming we get approval that the standards track is appropriate. Of the three scenarios you proposed for sending information on the Reverse Path, the answer is definitely #2: >1. Declare a new format, of type "jpeg-request" and use the data portion > of the packet to make my request. No. Data is only sent on the forward path. Also, defining new data types just for control information on another data type would be wasteful of the format number space, and require a binding of data formats and control formats. >2. Create a new option, and have there be no actual data in the packet. Yes. It is intended that applications will define their own application-specific options in the range 64-127. These may be used either for forward or reverse options. Fengmin mentioned the RAD (reverse application data) option that was defined in earlier drafts. This was eliminated because we could see no point in defining one RAD option and having each application define a subcode field within RAD and subcodes for a few suboptions within RAD, rather than just defining a few options in the range 64-127 instead. Different applications may use the same option numbers to mean different things without conflict because they are only interpreted by the application. We feel that the option space is not very limited compared to the expected need for option numbers. If an application needs lots of numbers, then that application should define one option and make is own subcode space of whatever size is appropriate. If we need to define some additional standard reverse or forward options in the future (e.g., in a new profile), those will be assigned in the option space below 64. >3. Use the "FMT" RTCP option, and insert my request in the format-dependent > section. No. The FMT option is used to define new values (or redefine old values) to go in the "format" field in the first word of the RTP header. The parameters in the format-dependent section are to describe to the entity interpreting the format how to do so. Initially we expect the predefined format values in the profile to be used, and that the FMT option won't be used until there is more variety in formats required. Note that new profiles may assign new or additional predefined format values. > I am thinking of using the Reverse-Path option to request JPEG > Quantization and Huffman Coding tables; my idea was that these > tables would be multicast once at the beginning of the conference, > and those who missed them could request them via a unicast > Reverse-Path packet. You should note the warning in the spec about the dangers of "ack implosion". If many receivers may have missed the tables, and are likely to request them at the same time, your sender may be overwhelmed by these requests. To alleviate this congestion, a new receiver should listen for a while to see if the tables get sent because some other receiver started a little bit earlier and requested them. If the tables are not heard during that timeout period, then the receiver in question can send its request. Now, that means there will be some delay when joining the session before you can interpret the data. How long should that delay be? For this particular problem, it has mostly to do with how long is reasonable for the user to wait. Since there may be stimuli that cause a number of receivers to join at the same time, it is important that the delay be randomly adjusted by each receiver so they don't all time out and send their requests at the same time. Carrying this further, if participation in the session is likely to be highly dynamic, then the source is likely to be sending out the tables in response to requests with some frequency. In this case, the the source could just send the tables periodically and no requests would be required at all. If the acceptable delay for hearing the tables is such that the tables could be sent periodically with an overhead of, say, one percent, then that's probably the right solution for all cases and never bother with the requests! Some food for thought. -- Steve ------- From rem-conf-request@es.net Fri Sep 24 21:15:23 1993 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <18335-0@osi-east.es.net>; Fri, 24 Sep 1993 18:08:46 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Fri, 24 Sep 1993 18:08:44 -0700 Posted-Date: Fri 24 Sep 93 18:07:58 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Fri, 24 Sep 93 18:08:03 PDT Date: Fri 24 Sep 93 18:07:58 PDT From: Stephen Casner Subject: RTP spec submission requested To: rem-conf@es.net Message-Id: <748919278.0.CASNER@XFR.ISI.EDU> Mail-System-Version: To the IETF Audio/Video Transport WG and other interested parties: Today completes the "last call for comments within the WG" period for the Real-Time Transport Protocol (RTP) specification and the accompanying "Encodings" and "Profile" drafts. There have been only a few comments; I hope that is because most of the concerns were addressed in the "next-to-last-call within the WG" round and in the subsequent teleconference discussion. I have requested that our Area Director, Allison Mankin, start the process of submitting the spec for publication as an RFC with the official Last Call within the IETF as a whole. She is expecting one more revision of the drafts to address these recent comments. Then, there may well be comments from the larger IETF community as well to be addressed before publication. For those who have not already picked up the Internet Drafts, they are available from the I-D repositories: Sep 15 17:30 draft-ietf-avt-rtp-03.txt Sep 15 14:10 draft-ietf-avt-rtp-03.ps Sep 17 20:45 draft-ietf-avt-encodings-02.txt Sep 17 20:45 draft-ietf-avt-profile-02.txt -- Steve Casner ------- From rem-conf-request@es.net Sat Sep 25 23:47:01 1993 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <23768-0@osi-east.es.net>; Sat, 25 Sep 1993 20:39:28 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Sat, 25 Sep 1993 20:39:16 -0700 Posted-Date: Sat 25 Sep 93 20:38:35 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Sat, 25 Sep 93 20:38:36 PDT Date: Sat 25 Sep 93 20:38:35 PDT From: Stephen Casner Subject: Should RTP be a standard? (long) To: rem-conf@es.net Message-Id: <749014715.0.CASNER@XFR.ISI.EDU> Mail-System-Version: Allison Mankin, the IETF Transport Area Director, asked the members of the Transport Area Directorate for their views on RTP and whether it should be a proposed standard. In response, Sally Floyd prepared a note reflecting her views from discussions at LBL with Van Jacobson and Steve McCanne and drawing on their experience with vat and wb. Sally was kind enough to forward her note to me for my response. We all felt it would be worthwhile to open this discussion to the larger rem-conf audience. Sally's note is included below, nearly verbatim, prefixed by "> " and with my responses interspersed sans prefix. > I don't believe that there needs to be a real-time transport protocol > that is used by all audio and video applications. ... I think I have a > different opinion that some of the people in the RTP working group > about the need for a single real-time transport protocol to be used by > all audio and video in the Internet. > > Van gave a talk at the ARPA PI meeting last week on architectures for > realtime applications and protocols. The main point, which I agree > with, was that the proper architecture for realtime applications does > not necessarily mirror the existing architecture for non-realtime > applications. Non-realtime applications such as telnet and ftp and > mail simply have some data that they hand over to a generic transport > protocol (tcp), expecting the transport protocol (along with the lower > layers) to provide reliable ordered delivery to the other end. Thus, > telnet and ftp and mail all require essentially the same interface to > the transport protocol; they hand over the data, and they expect the > data to be delivered to the application at the other end. > > With real-time applications, however, this model does not necessarily > carry over to a similar model of a generic realtime transport protocol. > (This all goes back to some remarks from Dave Clark on > application layer framing.) The realtime application doesn't require > generic (for example, TCP-style) congestion control or reliable ordered > delivery. Instead of having the application hand over the data to the > transport protocol, and having the transport protocol make the packets > and the packet headers, it might make more sense for the application > itself perform that function. I agree that it will often make a lot more sense for real-time applications to integrate the functions like those of RTP, rather than implementing them in a separate layer. We have never claimed that there should be a socket interface to RTP, for example. I think we're still learning how individual real-time applications and collections of such applications should be structured, and whether there are any common APIs to be factored out. However, I believe it is a separate question whether or not it makes sense to define a common protocol for multiple applications to implement as appropriate. It's a matter of costs and benefits. When we established the charter for the AVT WG, it was an open question whether the group should define separate protocols for different applications, or one common protocol. As we worked through the issues in the WG, we decided it was beneficial to define a single protocol. Fairly early in the process, I asked Van whether we should give up trying to define a common protocol for audio and video, and instead define separate protocols for each application. At that time, he said no. > This is not to argue that there is no use in the Internet for a > protocol like RTP; for some realtime applications RTP might fit > perfectly well, and it is certainly a good idea not to have everyone > have to reinvent all this from scratch every time they want to > implement a new audio or video application. Yes, there are many ways to gain from commonality other than as a shared layer: - an application designer or implementer carrying knowledge and experience from one application to another. - sharing code, perhaps through adaptation rather than as a library subroutine. - enabling the use of common monitoring and debugging tools, for example the packet loss monitoring that rtpqual can do, independent of application, or being able to dump the packets with tcpdump without having to add a chunk of code for each new application-specific protocol. - sharing auxilliary applications, such as recorders. Rather than have an audio recorder and a video recorder, you need only one. > This is simply to argue that the IETF should not move towards a > realtime architecture based on a single generic realtime protocol > for all audio and video applications. I've heard the phrase that what an Internet Standard means is that "if you do X, you should do it this way". I suppose this may carry more weight in lower layers than in higher ones, but does this mean that if RTP were established as a standard protocol all audio and video applications would be "required" to use it, and therefore it would be a bad idea to give RTP that status? My personal position would be that, certainly, if RTP is a poor fit for some real-time application, then some other protocol should be used or a new one designed. My guess is that RTP would be employed as it was found to be useful, and otherwise not (the old "market decides" method). > (Note that there are no interoperability concerns here, > given an application that is not attempting to interoperate with > different applications at the application level. Interoperability > would be a concern AFTER it had been decided that a generic realtime > protocol was needed. The question is one of the appropriate > architecture, apart from concerns of interoperability.) Hmmm. I think there are some interoperability concerns. The AVT WG was chartered because there were a number of experimenters building programs with private protocols, and the ability to interoperate was seen as a useful goal. Private protocols are fine until the time when there should be multiple implementations of an application, or until there is a need to interact with other applications. I mentioned above the example of a recorder application for audio and video. So, if there might be some benefits in a common protocol, what are the costs? To fit more than one application, the protocol will necessarily fit each one less well. However, I don't agree that as a result of the choices we've made, RTP may be useful for video but is not useful for audio. You've listed a few specific ways in which RTP is less suitable, so I'll try to address the cost of each. > Here are some specific examples from vat and RTP about why vat is more > suited to an application-specific protocol, and not to a generic > realtime protocol like RTP. > > 1. RTP essentially has a STOP bit (the end-of-synchronization unit), > as fits the needs of video applications to detect the end-of-frame. > Vat has a START bit, to detect the beginning of a talk spurt. Section > A of the RTP protocol shows how, with a few simple instructions, the > beginning of a talk spurt could be constructed from the STOP bit, but > why bother? Why bother? I've stated above a few reasons why I think a common protocol is useful. For a common protocol, the choice between STOP and START is clear because you can calculate the START from the STOP but not vice versa (at least not without introducing delay). What is the cost? A few simple instructions per packet in an application where it's common to execute a larger number of instructions for each byte of data in the packet. In other words, a negligible cost. Furthermore, there are some advantages to using the STOP bit for audio as well as video because it allows the receiver to know when packets are not arriving due to silence rather than packet loss. Receivers may want to replace silence by an appropriate background noise level to mask the sound/silence switching, but take some different action to reconstruct gaps due to lost packets. Also, if packet reordering occurs at the start of a talkspurt (which may be more likely than at other times due to several packets being sent at once then), the application may have to forego special start-of-talkspurt processing because it will already have processed a later packet before seeing the START bit. (I acknowledge that missing an occasional START is not crucial.) > 2. RTP has a 32-bit timestamp that is the middle 32 bits of a 64-bit > NTP timestamp. Vat uses a 32-bit timestamp that is generated by the > audio source and incremented by one at fixed intervals that match the > sampling rate of the audio source. This is the timestamp that best > suits the adaptive-playback algorithm of vat (and of other audio > applications, I think), particularly as different audio applications > might have different sample rates. Section A of the RTP protocol shows > how a fully-specified NTP timestamp could be extrapolated from the RTP > timestamp, but this is not what Vat needs, either; the Vat application > knows best what the appropriate timestamp is for the Vat receiver, and > there is no reason to think that the most appropriate timestamp for > video applications is also the most appropriate time for all audio > applications. (Video needs to know the frame, and the delta from the > frame; audio is oriented towards continuous realtime.) The timestamp is perhaps the most significant difference, but in my opinion, the benefits still outweigh the cost. First, I want to argue that the timestamp, in whatever units, should be related to real time to facilitate inter-stream synchronization. There's much more than this that must be done to implement synchronization, but many people believe that using globally synchronized clocks is the most practical way to implement synchronization. It seems to me that it makes much more sense for each sender to relate its data to real time than for all the receivers to keep track for each sender of the relationship between the source sample clock and real time. For example, in BBN's Synchronization Protocol, there is a requirement for a timestamp related to synchronized time to be carried with the data. As I said, these timestamps could still be in units of audio sample times, just as in vat now, but the timestamp would periodically be adjusted (usually during silence) to correct for skew between the sampling clock and real time. Now, what should the units be? We considered allowing the units to be chosen by each application and specified by prearrangement (for example, in a profile), or by periodic communication in an option, or some other out-of-band technique. However, we decided this extra complexity was not justified by the cost of using a common unit. That cost is basically one floating point multiply per packet at the sender and receiver to translate into and out of the common units. Most modern hardware (SPARCs, 486's) supports floating point, but this conversion can still be practical even without it. It is our belief, though not proven, that this technique of converting in and out of the standard units does not introduce any error. Again, I claim this cost is negligible. Assuming a common unit, I believe it makes a lot of sense to borrow from NTP as a standard. We chose the middle 32 bits as a tradeoff for overhead efficiency because that gave us sufficient resolution and range. It may beneficial for the audio application to maintain the timestamp for each packet in both NTP and sampling-clock units in that some time related operations have nothing to do with the sampling rate, and it may simplify the code to avoid percolating knowledge of the sampling rate into those parts of the code. Even if there is no benefit for the vat-type application, having a common timestamp (and protocol) allows the use of a single recorder program for multiple media, and allows that recorder program to play back multiple streams in sync if the original timestamps were in fact synchronized to real time. Right now, Anders Klemets has had to implement two separate recorders for vat and nv (RTP), and the playback gets out of sync because the clock skew between the audio and video is not known. Application-independent performance monitoring programs can also take advantage of the common timestamp units. If experience shows that we made the wrong decision, then RTP can be changed to incorporate adjustable timestamp units without invalidating any previous applications that use the standard units. > 3. RTP has a 16-bit sequence number in the header. Vat does not use a > sequence number. (Yes, the sequence number could be useful to some > audio applications to detect the loss of one of the > beginning-of-a-talk-spurt packets, but different applications make > different tradeoffs, and the decision in vat has been to forgo sequence > numbers. Thus, vat can do without the overhead of a sequence number.) Measuring packet loss rate is a fairly important function for the real-time applications. Without the sequence number, if the packet with the START bit is lost, you can't tell whether the gap in packets (as detected from the timestamps, assuming you know how much time each packet represents) was due to packet loss or silence. Even if the START bit is not lost, you don't know how many packets may have been lost from the end of the previous talkspurt. One may be able to calculate the loss rate by having the sender periodically communicate the number of packets transmitted as related to timestamps, but that is quite a bit more complicated. It seems to me that overhead is not a question when comparing RTP and the vat protocol because the headers are the same size. In the same space where RTP carries the sequence number, vat carries a conference id. You might express a concern that RTP does not satisfy vat's requirements because the conference id is omitted, but from my limited understanding of vat, in practice there is not much dependence upon the conference id. From Van's July 1992 description, - a 'conference id' discriminator to augment the multicast destination address and udp destination port in identifying packets for a particular conference. (This is partly because the multicast addr/port space is too small to avoid collisions if we randomly generate conference identifiers and partly because old versions of bsd (i.e., the code that most vendors ship) makes it very hard to use the multicast destination as part of the discriminator when you have multiple active conferences on one host.) The conference id reduces the probability of collision, but it's not a very appealing solution because the application will still be loaded down by processing of packets that it must discard when the conference id does not match. The address space is plenty big enough without the conference id for the current level of use, and I expect that the multicast address space will increase with IPng, such that this will not be a long-term concern. I expect other methods than random allocation will also be developed. A very high percentage of the hosts that have installed IP multicast extensions have also installed modifications to allow discriminating on multicast destinations. I believe we will be sucessful in spreading this change, so that old versions of bsd won't be a concern. Beyond these two purposes, the conference id can also be used to intentionally multiplex multiple conferences or streams within a conference to a single process while sharing a multicast address and destination port. RTP provides this functionality on a smaller scale (6 bits) which we deemed sufficient as we made our own tradeoffs. > 4. RTP uses unicast communications for relaying control information > from the receiver back to the sender. The provision for unicast > communications is not needed by Vat (and is not necessarily a great > idea in any case). RTP provides for both multicast and unicast communication of control information from the receiver back to the sender. An application need not use the unicast method, and the provision of the unicast method does not impose any cost on the application. Van says that all the communication should be multicast, and I expect that he is right most of the time. However, I believe there are some cases where ack-implosion is not an issue and where unicast communication is appropriate. We want to provide for that possibility in RTP, though it is important that we include warnings in the spec about the dangers of using unicast (and also multicast) inappropriately. To summarize these specifics, I don't find RTP to be ill-suited to the vat application or to other audio applications. RTP has been used for audio, in NEVOT. While it may be true that most of the benefits of using RTP might be to auxilliary applications rather than to vat itself, I find the cost to be negligible. I object to Van's characterization, at the PI meeting, of RTP as "bloated". The basic header size is exactly the same. The size of site identifications in a mixed packet is smaller. The equivalent of vat's ID message giving the user name is slightly longer, but also provides for the carriage of other forms of source descriptive information; since this information is sent at a low rate, the slight increase seems inconsequential. I admit the spec document is longer than we had hoped, but that has been the result of trying to add more explanation, and a sizeable chunk for security. I can't compare it to the vat protocol document since I have not seen one. To the extent that we know about the vat protocol, RTP provides a superset of its functionality. This should be no surprise since vat was a very important contribution to the RTP design process. I believe that vat could easily be converted to use RTP or to add RTP as another format, in the same way that vat now supports VT format. > This is to argue that whatever is done with RTP, it is not appropriate > to promote it as the generic real-time protocol to be used in the > Internet by all audio and video applications. I don't know about "the" and "all", as discussed above. I would like very much to see vat use RTP, but I don't know if it will ever happen. > The Internet does not need such a generic real-time protocol. I believe there is a need (demand) for RTP. > This does not mean that the current situation is ideal, either, with > an audio application like vat that is widely distributed, but that > is nevertheless still in flux and does not have a public release of > the source code. Hopefully this situation won't last forever... This I agree with! We've tried to capture the issues discussed in the AVT WG and the reasoning behind the design decisions for RTP in a companion document to the protocol specification. The goal was to allow those who had not participated in the protocol design to learn what was behind the design without having to rehash the arguments again in email as has happened for some other WGs. Unfortunately, the official I-D version of this document has expired, but it is available from gaia.cs.umass.edu as pub/rtp/issues_ps.ps or pub/rtp/issues.txt. We intend to submit an updated I-D soon for use during the IESG last-call period and for publication as a companion informational RFC. -- Steve ------- From rem-conf-request@es.net Sun Sep 26 08:34:23 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <24780-0@osi-east.es.net>; Sun, 26 Sep 1993 05:27:46 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 26 Sep 1993 13:27:34 +0100 To: Stephen Casner cc: rem-conf@es.net Subject: Re: Should RTP be a standard? (long) In-reply-to: Your message of "Sat, 25 Sep 93 20:38:35 PDT." <749014715.0.CASNER@XFR.ISI.EDU> Date: Sun, 26 Sep 93 13:27:34 +0100 From: Jon Crowcroft whilest the details here are very useful. io still think there is a strong case that we do NOT understand the distributed multiparty multimedia architecture however, i agree with steve, that RTP is a good vehicle for exploring a large chunk of the problem space...for now. but i certainly agree with the view that these type of applications are the ones that most benefit from application level framing/integrated layer processing, and thus do not lend themselves to the simple layering of mm-applic rtp ip(ng) since the applications incorporate a much larger degree of interaction with flow/congestion/loss/reorder mechanisms than any we have been used to, so the functions usually concentrated in the one end to end layer will tend to rove "up and down" depending on application, usage and connectivity... but i believe the RTP design recognizes this a lot by providing a common format without a complex set of elements of procedure... i.e. RTP isn't what i'd call a transport protocol but that doesnt matter, bewcause you don't want a 'transport, or end-to-end protocol at this point: the ends are the applications (vid/aud sources/sinks are part of the end to end path much more strongly than the the filesystems at each end of an FTP/tcp, or the keyboard/printer at each end of a telnet/tcp... so i think you are having a progrssive agreement:-) cheers jon From rem-conf-request@es.net Sun Sep 26 08:55:21 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <24828-0@osi-east.es.net>; Sun, 26 Sep 1993 05:49:33 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 26 Sep 1993 13:44:06 +0100 To: Lou Berger cc: CASNER@isi.edu, Christian.Huitema@sophia.inria.fr, st@ibminet.awdpa.ibm.com, rem-conf@es.net, END2END-INTEREST@isi.edu Subject: Re: ST-II and RSVP paper In-reply-to: Your message of "Fri, 24 Sep 93 12:07:08 EDT." Date: Sun, 26 Sep 93 13:44:04 +0100 From: Jon Crowcroft lou, thanks for your message - i agree with your (and my perceived bview of bbn's) attidute to ST >I see that ST fills the gap until the next generation protocols (e.g. >RSVP) that solve the problems that ST solves, without its failings, are >available. For me, it's not ST vs RSVP, it's ST now and a replacement >when its available. absolutely - just that the notion of 13 different implementations (as per the ibm/berkom claim!) is alarming - i don't thinkl there is that much research to do in the area that we need more than 1 implementation per o/s platform (say 4 or 5!). >The new ST working group has a limited focus. Its goal is to produce a >I don't think that an ST working group conflicts with the existence of >other groups looking at alternative resource management mechanisms. The >ST working group has a different focus than other (to be formed) working >groups. It is focused on clarification and interoperability, not >protocol development. sounds v. reasonable! cheers jon From rem-conf-request@es.net Mon Sep 27 09:40:04 1993 Received: from ninet.research.att.com by osi-east.es.net via ESnet SMTP service id <29741-0@osi-east.es.net>; Mon, 27 Sep 1993 06:16:19 +0000 Received: by research.att.com; Mon Sep 27 09:15 EDT 1993 Date: Mon, 27 Sep 93 09:14:11 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: ietf@cnri.reston.va.us, rem-conf@es.net, end2end-interest@isi.edu Subject: Call for Papers: JSAC special issue on the Internet Apologies to recipients of multiple copies. IEEE Journal on Selected Areas in Communications (JSAC) Call for Papers The Global Internet The Internet has grown from the dozen or so nodes of the original ARPAnet to a collection of more than 15,000 autonomous networks with around 1,800,000 hosts in 60 countries, forming the largest data network ever in existence. Its exponential growth and status as a component of the U.S. National Information Infrastructure have significantly enhanced interest in the Internet in the past few years. It also uniquely combines operational networks which large numbers of educational, research and commercial users depend on with an experimental network conducive to the rapid introduction of new services. Internet technology has found widespread use even in networks not physically connected to the Internet itself. In both organization and technical details, the Internet marks a departure from customary telecommunications and data networks, even though the underlying transmission technology is often similar. Many of the issues faced by the Internet today, in particular scaling, heterogeneity, security over untrusted links and integrated services, will confront both private and public (data) networks in the near future. Technical papers are solicited concerning key Internet problems including the following: o scaling and heterogeneity o novel applications for the Internet o routing, addressing and naming o support for mobility o integration of new technologies such as ATM, SMDS, frame relay and large public data networks with the Internet o information services and resource discovery o large-scale multicast o internet multimedia, such as real-time audio/video conferencing, signaling issues o quality-of-service issues in an internet o resource accounting and billing o privacy and security in internetworks Electronic submissions in PostScript, LaTeX or HTML formats are encouraged. Please contact Henning Schulzrinne by electronic mail for requirements. Electronic and paper submissions should be sent to Deborah Estrin only according to the following schedule: Manuscript submission: February 1, 1994 Acceptance notification: June 1994 Final manuscript due: August 1994 Publication date: 1st Quarter 1995 Guest Editors Jon Crowcroft Deborah Estrin University College London Computer Science Department mc0781 J.Crowcroft@cs.ucl.ac.uk University of Southern California Los Angeles, CA 90089-0781 Tel.: +1 213 740 4524 estrin@usc.edu Henning Schulzrinne Michael Schwartz AT&T Bell Laboratories University of of Colorado hgs@research.at.com schwartz@cs.colorado.edu From rem-conf-request@es.net Mon Sep 27 13:43:02 1993 Received: from uu2.psi.com by osi-east.es.net via ESnet SMTP service id <01817-0@osi-east.es.net>; Mon, 27 Sep 1993 10:31:24 +0000 Received: from port17.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA10306 for rem-conf@es.net; Mon, 27 Sep 93 13:30:56 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA09765; Mon, 27 Sep 93 10:28:31 PDT Message-Id: <9309271728.AA09765@aland.bbn.com> To: Stephen Casner Subject: Re: ST-II and RSVP paper Cc: J.Crowcroft@cs.ucl.ac.uk Cc: st@ibminet.awdpa.ibm.com, rem-conf@es.net, END2END-INTEREST@ISI.EDU From: Craig Partridge Date: Mon, 27 Sep 93 10:28:31 -0700 Sender: craig@aland.bbn.com > The initial ST-II flowspec had 14 parameters, of which two were really > return values, not parameters. In Craig Partridge's grand reduction > of parameters for the flowspec in RFC 1363, there are 10 parameters, > which doesn't sound so different to me. I've heard this point made before and after some thinking, I believe it's the wrong way to think about the problem. The question, in a larger sense, is how many knobs does the user have to turn? The two flow specs have very different philosophies about how to fully specify a particular piece of information (for example, RFC 1363 specifies data rates using a token bucket, while ST-II isn't clear about its transmission model, but seems to use three, DutyFactor, DesPDURate and DesPDUBytes) My view is that the original ST-II flow spec has ten (transmission rate [DutyFactor, DesPDUBytes, DesPDURate], ErrorRate, Precedence, Reliability, Tradeoffs, RecoveryTimeout, LimitOnCost, LimitOnDelay, LimitOnPDURate, MinBytesXRate) while RFC 1363 has six (transmission rate [all the token bucket params], Minimum Delay Noticed, Maximum Delay Variation, Loss Sensitivity, Burst Loss Sensitivity, Quality of Guarantee). Craig From rem-conf-request@es.net Mon Sep 27 16:15:31 1993 Received: from alpha.Xerox.COM by osi-east.es.net via ESnet SMTP service id <03432-0@osi-east.es.net>; Mon, 27 Sep 1993 13:09:25 +0000 Received: from kearsarge.parc.xerox.com ([13.2.116.189]) by alpha.xerox.com with SMTP id <11645(10)>; Mon, 27 Sep 1993 13:09:03 PDT Received: by kearsarge.parc.xerox.com id <2703>; Mon, 27 Sep 1993 13:08:52 -0700 Sender: Sugih Jamin From: jamin@parc.xerox.com (Sugih Jamin) Date: Mon, 27 Sep 1993 13:08:37 PDT Phone: +1 415 812 4834 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: hzhang@tenet.icsi.berkeley.edu (Hui Zhang), knightly@tenet.icsi.berkeley.edu Subject: Re: admission control Cc: end2end-interest@isi.edu, rem-conf@es.net Message-Id: <93Sep27.130852pdt.2703@kearsarge.parc.xerox.com> Hui and Ed, Thanks for your helpful comments. We used two kinds of traffic sources in our simulation. The first kind is as you described, with the additional detail that it follows the packet train model; it doesn't send continuously at the peak rate. The second is similar to the first, except that it periodically stops until the bucket fills up and then dumps 30 tokens worth of data back to back. While reserving guaranteed flows with b = 1 will have been sufficient for the first source model, we need to reserve b = 30 for the second kind. You are right in observing that our comparison was somewhat unfair, in that we used the value of b that applied only to the second source model. After reading your notes, we reran the simulations to rectify this. For the first source model, we expect utilization to go up when predictive service is used in place of guaranteed service. Predictive flows should be able to fill in the usage gaps between each others' packet trains. I ran a simulation with only predictive flows. All the flows generate data using the first source model at the peak rate of 160 Kbps, request for a max delay of 6.25 ms, and have token bucket filter with b = 1 (token size = data rate / token rate). And indeed I see a 80% utilization on the bottleneck link. This compares favorably with the 50% utilization you observed running only guaranteed service flows. We note that the traffic of this source model is not very bursty. Then I re-ran the simulation with only the second source model. All flows request max delay of 20 ms, and have token bucket filter with b = 30. The utilization I get is slightly less than 70%. With the second source model, we need to reserve b = 30 even when running with guaranteed service. To achieve 20 ms delay, we would then need to ask for 1.5 Mbps per flow, driving down utilization to 7%. In this case when the traffic is very bursty, we do see an order of magnitude increase in utilization by introducing predictive service. We also expect to see further increase in utilization when we have multiple classes of predictive service. Anyway, I hope that clarifies some of the confusions we had. If you have other related questions, we could pursue this discussion off-line. -- sugih From rem-conf-request@es.net Mon Sep 27 16:26:00 1993 Received: from odin.ucsd.edu by osi-east.es.net via ESnet SMTP service id <03599-0@osi-east.es.net>; Mon, 27 Sep 1993 13:20:15 +0000 Received: from kailas.ucsd.edu by odin.ucsd.edu; id AA20226 sendmail 5.67/UCSDPSEUDO.4-CS via SMTP Mon, 27 Sep 93 10:05:50 -0700 for rem-conf@es.net Received: by kailas (5.67/UCSDPSEUDO.4) id AA14339 for mm-announcement-list@odin; Mon, 27 Sep 93 10:05:47 -0700 Date: Mon, 27 Sep 93 10:05:47 -0700 From: mm@cs.ucsd.edu (Multimedia Project) Message-Id: <9309271705.AA14339@kailas> To: mm-announcement-list@cs.ucsd.edu Subject: Call for Papers - ACM SIGMETRICS'94 CALL FOR PAPERS 1994 ACM SIGMETRICS Conference on Measurement and Modeling of Computer Systems May 16-20, 1994 Vanderbilt University Nashville, Tennessee Performance evaluation is fundamental to designing, implementing, and understanding computer systems. This conference provides an international forum for state-of-the-art work on performance issues in computer systems. Papers describing the application of performance evaluation techniques to computer system design, presenting new techniques, or describing extensions to existing techniques are welcome. We also invite original case studies in which performance evaluation techniques have been usefully applied. Topics of interest include, but are not restricted to: Performance-oriented design and evaluation studies of: Communication networks Computer system architecture Database and transaction processing systems Distributed systems Fault-tolerant systems File and I/O systems High speed networks, ATM Interconnection networks Memory systems Multimedia systems Operating systems Parallel systems Real-time systems Supercomputers Techniques and algorithms for: Experimental design of performance studies Stochastic modeling, e.g., queueing networks, Petri nets Model verification and validation Performance optimization System measurement Reliability analysis Reliability management System performance management Simulation and statistical analysis Workload characterization Visualization All papers will be refereed by members of the program committee who are most familiar with the topic and by outside referees. Paper publication is very competitive, with typically fewer than 25% of submissions accepted. In addition, a limited number of the submitted papers will be accepted for a poster session. Extended abstracts of the poster session papers will be included in the conference Proceedings. The Proceedings will be distributed to conference attendees and published as a special issue of ACM SIGMETRICS Performance Evaluation Review. We are also soliciting proposals from prospective instructors for 1.5 hour and 4 hour pre-conference tutorials. Paper submissions should not exceed 20 double-spaced pages (excluding figures and tables). Nine (9) copies are required. Author identification, including affiliation, address, phone number, and electronic mail address should appear on a separate cover sheet and NOT within the paper itself. Tutorial proposals should be 1-2 pages and may be submitted electronically. For more information about submissions, contact either the Program Chair or the Tutorials Chair. This year we will be expanding our awards program. Award paper(s) will be selected and forwarded to an appropriate journal. Student award paper(s) will be selected and appropriately recognized. (To qualify for a student paper award, the cover letter should clearly specify that the primary author is a full-time student.) Best presentation and service awards are also planned. Submit papers by October 22, 1993 to: Rick Bunt, Program Chair Department of Computational Science University of Saskatchewan Saskatoon, SK S7N 0W0 CANADA bunt@cs.usask.ca (306) 966-4890 Submit tutorial proposals by September 15, 1993 to: David Nicol, Tutorials Chair Department of Computer Science College of William and Mary Williamsburg, VA 23187-8795 USA nicol@cs.wm.edu (804) 221-3458 Notification of acceptance/rejection of submitted papers will be made by January 24, 1994 and the camera-ready copy will be due February 22, 1994. For further information about the conference, contact the General Chair, Larry Dowdy, Dept. of Computer Science, Vanderbilt University, Box 1679, Station B, Nashville, TN 37235 (lwd@vuse.vanderbilt.edu (615) 322-3031). Conference Committee General Chair: Larry Dowdy, Vanderbilt University, lwd@vuse.vanderbilt.edu Ray Bryant (IBM) -- Publicity Co-Chair Rick Bunt (Univ. of Saskatchewan) -- Program Chair Brian Carlson (Dakota State Univ.) -- Posters Chair Larry Dowdy (Vanderbilt Univ.) -- General Chair Karen Gordon (IDA/Vanderbilt) -- Registration Chair Bill Hooper (Belmont Univ.) -- Local Arrangements Chair Rajeev Jog (Kubota Pacific) -- Proceedings Chair Tom Keller (IBM) -- Finance Chair David Nicol (William and Mary) -- Tutorials Chair K.K. Ramakrishnan (DEC) -- Book Display Chair Herb Schwetman (MCC) -- Publicity Co-Chair Guiseppe Serazzi (Politec. Milano) -- Publicity Co-Chair Connie Smith (Perf. Eng. Services) -- Awards Chair Program Committee Program Chair: Rick Bunt, University of Saskatchewan, bunt@cs.usask.ca Tom Anderson (UC Berkeley) Simonetta Balsamo (University of Pisa) Rick Bunt (University of Saskatchewan) Garth Gibson (Carnegie Mellon University) Anoop Gupta (Stanford University) Geunter Haring (Universit a t Wien) Joe Hellerstein (IBM) Ulrich Herzog (University of Erlangen-Nurnberg) Mark Holliday (Duke University) Raj Jain (DEC) Dick Muntz (UCLA) Harry Perros (North Carolina State University) Venkat Rangan (UC San Diego) Ken Sevcik (University of Toronto) Satish Tripathi (University of Maryland) Mary Vernon (University of Wisconsin) Carey Williamson (University of Saskatchewan) Murray Woodside (Carleton University) From rem-conf-request@es.net Mon Sep 27 17:40:21 1993 Received: from interlock.ans.net by osi-east.es.net via ESnet SMTP service id <04477-0@osi-east.es.net>; Mon, 27 Sep 1993 14:34:17 +0000 Received: by interlock.ans.net id AA03856 (InterLock SMTP Gateway 1.1 for rem-conf@es.net); Mon, 27 Sep 1993 17:28:01 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Sep 1993 17:28:01 -0400 Message-Id: <199309272128.AA40166@home.ans.net> To: Stephen Casner Cc: rem-conf@es.net Subject: Re: Should RTP be a standard? (long) In-Reply-To: (Your message of Sat, 25 Sep 93 20:38:35 PDT.) <749014715.0.CASNER@XFR.ISI.EDU> Date: Mon, 27 Sep 93 17:28:22 -0500 From: Phill Gross In a recent message to the rem-conf list, Steve Casner made the following comment: I've heard the phrase that what an Internet Standard means is that "if you do X, you should do it this way". I suppose this may carry more weight in lower layers than in higher ones, but does this mean that if RTP were established as a standard protocol all audio and video applications would be "required" to use it, and therefore it would be a bad idea to give RTP that status? I've used that quote myself. (Ahem, I may have originated it.) Sounds like we should clarify what it means in the "modern" IETF. There's two ways to paraphrase the above quote, depending upon whether you are talking about 1) entering a protocol into the standards track or 2) making an "applicability statement" about a protocol already in the standards track: 1) If you are talking about entering protocol into the standards track, then the quote might be -- "If you want to do this *protocol* (eg, IS-IS or OSPF), then for the purposes of protocol interoperability, you should do the protocol in this *standard* way". 2) If you are talking about the "applicability" of a protocol already in the standard's track, then the quote might be -- "If you want to do this *function* in the Internet (eg, intra- domain routing), then, for the purposes of having at least one common way among all Internet users for performing the function, this *protocol* (eg, OSPF) is recommended. In some cases, the Applicability Statement may be aimed at *vendors* (eg, the intent is to make sure that there is at least one common protocol available for users should they choose to use it. This is the case with OSPF). In other cases, the applicability statement may aimed at *users* (eg, the intent is to RECOMMEND, or in some case even REQUIRE, the use of a certain protocol for a function. For example, IP is the Required internetworking protocol for the Internet)." If there are good reasons, there can be multiple protocols to do the same *function* (eg, there are multiple intra-domain routing protocols in the standards track). We don't want to create multiple protocol standards for the same function in a willy-nilly fashion, but if there are justifiable reasons for it, then it's ok to do so. (In the case of real-time transport protocols, I gather from the message that there may reasons for multiple real-time transport protocols with different characteristics. Depending on the strength of the argument, it may be ok to standardize more than one.) Don't know if this makes it any clearer. You can always refer to RFC 1310 which specifies the Internet standards process. It is now in the process of being updated. Please see the new Internet-Draft for more precise details on the above topics. Phill From rem-conf-request@es.net Mon Sep 27 18:53:03 1993 Received: from picard.cmf.nrl.navy.mil by osi-east.es.net via ESnet SMTP service id <05177-0@osi-east.es.net>; Mon, 27 Sep 1993 15:47:07 +0000 Received: from herman.cmf.nrl.navy.mil by picard (4.1/SMI-4.1) id AA09548; Mon, 27 Sep 93 14:18:50 EDT Received: from localhost by herman.cmf.nrl.navy.mil (4.1/client-1.3) id AA21478; Mon, 27 Sep 93 14:18:46 EDT Message-Id: <9309271818.AA21478@herman.cmf.nrl.navy.mil> To: Stephen Casner Cc: rem-conf@es.net Subject: Re: Usage of the Reverse-Path option (section 5.3) In-Reply-To: Your message of "Fri, 24 Sep 93 17:14:08 PDT." <748916048.0.CASNER@XFR.ISI.EDU> Date: Mon, 27 Sep 1993 14:18:27 -0400 From: William C Fenner On Fri 24 Sep 93 17:14:08 PDT Stephen Casner wrote: > Data is only sent on the forward path. In "normal" teleconferencing, I agree. However, there may be applications where you have a central data collector multicasting data out, and I see no reason why corrections and/or updates to the data couldn't come in via reverse-path packets. > >2. Create a new option, and have there be no actual data in the packet. > > Yes. It is intended that applications will define their own > application-specific options in the range 64-127. I'd like to suggest that a small space (8? 16?) of option numbers be designated as format-specific options. In this case, the options are really specific to the format, not to the application. When Joe Blow comes along with his new application WonderVid, he shouldn't have to worry about implementing nv application-specific options. > Different > applications may use the same option numbers to mean different things > without conflict because they are only interpreted by the application. I'm just worried about different applications having to use different numbers to mean the same thing. How does a receiver know what application the sender is running, so that it knows what application-specific options it may use? Bill From rem-conf-request@es.net Tue Sep 28 10:05:42 1993 Received: from thdsun.EPM.ORNL.GOV by osi-east.es.net via ESnet SMTP service id <09896-0@osi-east.es.net>; Tue, 28 Sep 1993 06:26:06 +0000 Received: by thdsun.EPM.ORNL.GOV (4.1/1.34) id AA22423; Tue, 28 Sep 93 09:25:55 EDT Date: Tue, 28 Sep 93 09:25:55 EDT From: dunigan@thdsun.EPM.ORNL.GOV (Tom Dunigan 576-2522) Message-Id: <9309281325.AA22423@thdsun.EPM.ORNL.GOV> To: rem-conf@es.net Subject: audio out (RCA) in to Sun microphone jack -- how. Just taking the audio out from a VCR/TV (RCA jack) and patching it directly into the the microphone-in (mini jack) of a Sun to use as a feed for vat yields a somewhat distorted audio. (We get better audio by just laying the microphone over the speaker, but then that picks up room bacground noise too.) So what does one need to "match impedance" (or whatever, I just do software) to get the audio-out/mic-in patch to provide good sound quality? thanks From rem-conf-request@es.net Tue Sep 28 10:55:08 1993 Received: from norman.nwnet.net by osi-east.es.net via ESnet SMTP service id <10580-0@osi-east.es.net>; Tue, 28 Sep 1993 07:45:19 +0000 Received: by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA22646; Tue, 28 Sep 93 07:44:58 -0700 Date: Tue, 28 Sep 1993 07:40:52 -0700 (PDT) From: Allen Robel Subject: Re: audio out (RCA) in to Sun microphone jack -- how. To: Tom Dunigan 576-2522 Cc: rem-conf@es.net In-Reply-To: <9309281325.AA22423@thdsun.EPM.ORNL.GOV> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 28 Sep 1993, Tom Dunigan 576-2522 wrote: > Just taking the audio out from a VCR/TV (RCA jack) and patching > it directly into the the microphone-in (mini jack) of a Sun to use > as a feed for vat yields a somewhat distorted audio. (We get better > audio by just laying the microphone over the speaker, but then > that picks up room bacground noise too.) So what does one need > to "match impedance" (or whatever, I just do software) to get the > audio-out/mic-in patch to provide good sound quality? You might try an in-line attenuator. Radio Shack sells them at varying degrees of attenuation (measured in db) for a few dollars a piece. This is just a guess, but it sounds (no pun intended) like the mic level input is being overloaded by the line level out of the VCR (don't quote me on that though...) Allen Robel Internet: allen@nwnet.net Network Engineer voice: (206)562-3000 NorthWestNet FAX: (206)562-4822 From rem-conf-request@es.net Tue Sep 28 12:27:59 1993 Received: from alpha.Xerox.COM by osi-east.es.net via ESnet SMTP service id <11903-0@osi-east.es.net>; Tue, 28 Sep 1993 09:27:21 +0000 Received: from reynaldo.parc.xerox.com ([13.2.116.96]) by alpha.xerox.com with SMTP id <11755(3)>; Tue, 28 Sep 1993 09:26:57 PDT Received: by reynaldo.parc.xerox.com id <25545>; Tue, 28 Sep 1993 09:26:54 -0700 From: Berry Kercheval To: Allen Robel Cc: Tom Dunigan 576-2522 , rem-conf@es.net Subject: Re: audio out (RCA) in to Sun microphone jack -- how. In-Reply-To: References: <9309281325.AA22423@thdsun.EPM.ORNL.GOV> Reply-To: kerch@parc.xerox.com Message-Id: <93Sep28.092654pdt.25545@reynaldo.parc.xerox.com> Date: Tue, 28 Sep 1993 09:26:39 PDT Allen Robel writes: > On Tue, 28 Sep 1993, Tom Dunigan 576-2522 wrote: > > > Just taking the audio out from a VCR/TV (RCA jack) and patching > > it directly into the the microphone-in (mini jack) of a Sun to use > > as a feed for vat yields a somewhat distorted audio. > [...] but it sounds (no pun intended) like the mic level input > is being overloaded by the line level out of the VCR ... This is exactly what happened to me when I patched a MIDI synthesizer into a VAT. It turned out I was able to turn the master gain on the synth down far enough to keep the Sun mike from overloading, but in the VCR case there probably isn't a gain control on the line out. By all means, try an attenuator. If nothing else, you can get an L-pad and a handful of jacks'n'cables at Radio Shack and build an adjustable in-line attenuator for less than ten bucks. --berry From rem-conf-request@es.net Tue Sep 28 12:30:29 1993 Received: from swiss.ucs.ubc.ca by osi-east.es.net via ESnet SMTP service id <11944-0@osi-east.es.net>; Tue, 28 Sep 1993 09:29:52 +0000 Received: by swiss.ucs.ubc.ca (4.1/1.14) id AA29774; Tue, 28 Sep 93 09:29:42 PDT Date: Tue, 28 Sep 1993 09:29:05 -0700 (PDT) From: Helen Salter Subject: please add me to your mailing list To: rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII thanks. Helen Salter University Computing Services salter@ucs.ubc.ca University of British Columbia 604-822-5736 6356 Agricultural Road Fax: 604-822-5116 Vancouver B.C. Canada V6T 1Z2 From rem-conf-request@es.net Tue Sep 28 12:57:57 1993 Received: from sun2.nsfnet-relay.ac.uk by osi-east.es.net via ESnet SMTP service id <12138-0@osi-east.es.net>; Tue, 28 Sep 1993 09:47:37 +0000 Via: uk.ac.edinburgh.castle; Tue, 28 Sep 1993 17:47:01 +0100 Received: from scorpio.castle.ed.ac.uk by castle.ed.ac.uk id aa21004; 28 Sep 93 17:46 BST Date: Tue, 28 Sep 93 17:46:54 BST Message-Id: <10623.9309281646@scorpio.ucs.ed.ac.uk> From: Graeme Wood Subject: Re: audio out (RCA) in to Sun microphone jack -- how. To: Tom Dunigan 576-2522 , rem-conf@es.net In-Reply-To: Tom Dunigan 576-2522's message of Tue, 28 Sep 93 09:25:55 EDT Reply-To: Graeme.Wood@edinburgh.ac.uk X-Department: Unix Systems Support, Computing Services X-Organisation: The University of Edinburgh X-Phone: +44 (0)31 650 5003 X-Fax: +44 (0)31 662 4712 Sender: jaw <@uk.ac.ed.castle.scorpio:jaw@castle.edinburgh.ac.uk> > Just taking the audio out from a VCR/TV (RCA jack) and patching > it directly into the the microphone-in (mini jack) of a Sun to use > as a feed for vat yields a somewhat distorted audio. (We get better > audio by just laying the microphone over the speaker, but then > that picks up room bacground noise too.) So what does one need > to "match impedance" (or whatever, I just do software) to get the > audio-out/mic-in patch to provide good sound quality? We use one of those nice attenuators you get with and Apple Macintosh. It works a treat. Graeme From rem-conf-request@es.net Tue Sep 28 13:14:00 1993 Received: from research.att.com by osi-east.es.net via ESnet SMTP service id <12392-0@osi-east.es.net>; Tue, 28 Sep 1993 10:07:51 +0000 From: kanakia@research.att.com Date: Tue, 28 Sep 93 13:04:49 EDT To: rem-conf@es.net Sugih, thanks for the pointer to your paper. It is interesting. fills in details for CSZ service model for predicted service. This should be a good companion paper to read for attendees of IETE-BOF on CSZ service model. It brings home (at least it did to me) the complexity involved in implementing the model at a switch. The paper is a first step in quantifying benefits the predicted service will bring. But for now, the paper raises more questions than settles them. Apart from the things that Hui Zhang has pointed out, I have the following comments. 1. Use "real sources". Leaky bucket models or other simple bursty traffic models leave out some important things from the comparison. Using real sources will show how well the prediction algorithms implemented at switch works. It will also allow one to see the impact of delay bounds on actual "quality of service" which should not be taken as self-evident. 2. The comparison is apples-to-oranges. The predicted service model does not provide any guarantees, thus, it is not kosher to compare it with disciplines that do make guarantees. More meaningful to compare service quality of the proposed algorithm versus that provided by simple FQ or round-robin algorithm. At the least, adding this comparison would serve as a check on the accuracy of your simulations. In particular, you should not see more network utilization than that seen with FQ discipline. 3. The framework for comparison assumes that bounds on delays are really meaningful to users. Are RT videos that are maximum delay bounded by 10 ms better than those maximum delay bounded by 100 ms? why? both fall within limits of interactive dialogues. 4. What is still left unclear is how does one choose a predicted class that it should belong to. Consider that a stream would like 100 ms maximum delay. Does the source have to know how many switches are there in the path? do you select 100 ms divided by the number of switches in the path as the bound for each switch? Does that predicted class remain same at all switches along the path? The simple scenario of two switches connected by a single link considered in the paper is not forced to settle questions of this type. I could go on and provide more specific comments in personal mails but for now I would be off the air on the subject. flames go to /dev/null. If you do make more comparisons or come across others which have studied CSZ model in detail, please send me the pointers. Hemant From rem-conf-request@es.net Tue Sep 28 13:14:19 1993 Received: from citi.umich.edu by osi-east.es.net via ESnet SMTP service id <12316-0@osi-east.es.net>; Tue, 28 Sep 1993 10:02:04 +0000 Received: from aqaba.citi.umich.edu by citi.umich.edu with SMTP; Tue, 28 Sep 93 13:01:28 -0400 From: Jim.Rees@umich.edu To: rem-conf@es.net Date: Tue, 28 Sep 93 13:01:27 EDT Subject: Re: audio out (RCA) in to Sun microphone jack -- how. In-Reply-To: Allen Robel, Tue, 28 Sep 93 07:40:52 PDT This is just a guess, but it sounds (no pun intended) like the mic level input is being overloaded by the line level out of the VCR (don't quote me on that though...) That's a true fact, as we say. Microphone levels are typically at least 50 db down from line level. You can make your own attenuator if you like, with a 100 K resistor in series with the line output and a 4.7 K resistor in parallel with the mic input. The values are not critical. If you buy an attenuator from the Rat Shack, look for 20 to 40 db. From rem-conf-request@es.net Tue Sep 28 14:12:27 1993 Received: from ibminet.awdpa.ibm.com by osi-east.es.net via ESnet SMTP service id <13264-0@osi-east.es.net>; Tue, 28 Sep 1993 11:04:18 +0000 Received: by ibminet.awdpa.ibm.com (5.61/1.15) id AA28764; Tue, 28 Sep 93 11:05:02 -0700 Received: from [9.228.10.104] by ibmpa.awdpa.ibm.com (5.65b(em1)/2.06) id AA04355; Tue, 28 Sep 93 10:51:00 -0700 Received: by kiwi.heidelbg.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA10910; Tue, 28 Sep 1993 18:50:33 +0200 From: ibmpa!kiwi.heidelbg.ibm.com!luca@ibminet.awdpa.ibm.com (Luca Delgrossi) Message-Id: <9309281650.AA10910@kiwi.heidelbg.ibm.com> Subject: 2 papers on ST-II To: st%ibminet.awdpa.ibm.com@ibmpa.heidelbg.ibm.com (ST WG Discussion List), end2end-interest%isi.edu@ibmpa.heidelbg.ibm.com (End2End Interest), rem-conf%es.net@ibmpa.heidelbg.ibm.com (Rem-Conf WG Discussion List) Date: Tue, 28 Sep 1993 18:50:33 +0100 (DFT) Reply-To: luca@ibmpa.awdpa.ibm.com X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1208 I finally placed on our file server the two papers on ST-II I mentioned last week. They can be retrieved from: host: ibminet.awdpa.ibm.com dir: pub/st The file "st2-impl.ps" contains a paper describing our ST-II implementation. The paper will appear on Internetwork: Research and Experience after some minor changes. The file "st2-recv.ps" contains a paper describing our extensions to ST-II for receiver-initiated communication. Please note that this is a preliminary version. Both papers are in PostScript format. Any comments are more than welcome. Have fun! Luca -- +-------------------------------------------------------------------+ | Luca Delgrossi luca@ibmpa.awdpa.ibm.com | +----------------------------------+--------------------------------+ | IBM European Networking Center | INET: luca@ibmpa.awdpa.ibm.com | | Distributed Multimedia Solutions | EARN: luca@dhdibm1.bitnet | | Vangerowstr. 18 | VNET: LUCA at HEIDELBG | | D69115 Heidelberg 1 | tel : +49-6221-594330 | | Germany | fax : +49-6221-593400 | +----------------------------------+--------------------------------+ From rem-conf-request@es.net Tue Sep 28 15:04:51 1993 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <13522-0@osi-east.es.net>; Tue, 28 Sep 1993 11:31:47 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Tue, 28 Sep 1993 11:31:44 -0700 Posted-Date: Tue 28 Sep 93 11:31:02 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Tue, 28 Sep 93 11:31:03 PDT Date: Tue 28 Sep 93 11:31:02 PDT From: Stephen Casner Subject: Re: audio out (RCA) in to Sun microphone jack -- how. To: allen@nwnet.net, dunigan@thdsun.epm.ornl.gov Cc: rem-conf@es.net Message-Id: <749241062.0.CASNER@XFR.ISI.EDU> In-Reply-To: Mail-System-Version: > > Just taking the audio out from a VCR/TV (RCA jack) and patching > > it directly into the the microphone-in (mini jack) of a Sun to use > > as a feed for vat yields a somewhat distorted audio. > > You might try an in-line attenuator. Radio Shack sells them at varying > degrees of attenuation (measured in db) for a few dollars a piece. I've only seen one in-line attenuator at Radio Shack, part number 274-300 (RCA phono jack to 1/8" mono phone plug). This is a 40dB attenuator, which I've found to work well for the higher line level of professional audio equipement. For output from consumer equipment such as a VCR, I experimented and found that 24dB was better because it allows setting a lower microphone level on vat which reduces the noise level contributed by the SPARC input circuitry. You can make one with the appropriate connectors and a couple of resistors: ----------------15K------+----------- | source 1K SPARC | -------------------------+----------- By the way, this is for the older SS1 and SS2 class machines. On the new machines with a SoundBox, there is a line input (and in fact, I have not been successful trying to attenuate and use the mic input). -- Steve ------- From rem-conf-request@es.net Wed Sep 29 19:32:30 1993 Received: from ucsd.edu by osi-east.es.net via ESnet SMTP service id <16051-0@osi-east.es.net>; Wed, 29 Sep 1993 16:22:47 +0000 Received: from celece.ucsd.edu by ucsd.edu; id AA15649 sendmail 5.67/UCSD-2.2-sun via SMTP Wed, 29 Sep 93 16:22:46 -0700 for rem-conf@es.net Received: from [132.239.19.189] (infoscope.UCSD.EDU) by celece (4.1/UCSDPSEUDO.4) id AA11313 for rem-conf@es.net; Wed, 29 Sep 93 16:22:43 PDT Message-Id: <9309292322.AA11313@celece> Date: Wed, 29 Sep 1993 16:23:52 -0800 To: rem-conf@es.net From: jain@ece.UCSD.EDU Subject: IEEE Multimedia Cc: jain@ece.UCSD.EDU Call for Participation IEEE Multimedia Magazine The planning for the IEEE Multimedia Magazine is progressing smoothly. The editorial board for the magazine is being formed and approved by the IEEE Computer Society Publications Board. Different sections of the magazine are at various stages of planning. The premier issue is expected to be available in the first quarter of 1994. The magazine will cover all aspects of multimedia, including hardware, software, and applications. It will contain several sections like, reviews of media, multimedia, and usual sections like calendar of events, reports on important events in the field. Many papers published in the magazine will be tutorial or overview paper on some aspect of multimedia technology or its application. Research and application papers will also be written for a wider audience. These papers will be usually about 20 A4 pages (about 6 printed pages), including figures and about 10 references. You are invited to contribute to the magazine by contributing a paper, or helping in different sections. Your ideas to start new sections are most welcome. For rapid publications of your papers in any aspect of multimedia technology, this may be the best time. There is no backlog of papers and early issues will get wide publicity. Please contact the Editor-in-Chief for getting more information about the magazine or for volunteering your help in any other aspect of the magazine, at: Ramesh Jain Electrical and Computer Engineering Dept. 4602 EBU 1 University of California at San Diego La Jolla, CA 92093 Tel: 619-534-8639 Fax: 619-534-2486 email:jain@ece.ucsd.edu Also please help us in building a database of reviewers for the magazine by sending the enclosed form to the EIC. -------------------------------Cut Here-------------------------------- I would like to review the papers in the following areas for the IEEE Multimedia magazine: (list all areas of your expertise and interest) I would like to get 2 weeks 4 weeks 6 weeks for reviewing papers. I would like to contribute to following sections of the magazine (suggestions for new sections are welcome): My complete address is (include e-mail, phone, and fax): ______________________________________________ Ramesh From rem-conf-request@es.net Thu Sep 30 01:18:46 1993 Received: from ux5.lbl.gov by osi-east.es.net via ESnet SMTP service id <18574-0@osi-east.es.net>; Wed, 29 Sep 1993 22:02:31 +0000 Received: from intruder.lbl.gov.csd by ux5.lbl.gov (4.1/1.39) id AA27920; Wed, 29 Sep 93 22:02:17 PDT Received: from localhost by intruder.lbl.gov.csd (4.1/SMI-4.1) id AA05447; Wed, 29 Sep 93 22:02:14 PDT Message-Id: <9309300502.AA05447@intruder.lbl.gov.csd> To: rem-conf@es.net Reply-To: CTLarsen@lbl.gov Subject: National Information Infrastructure (NII) Education Forum Announcment Date: Wed, 29 Sep 1993 22:02:11 -0700 From: Case Larsen The "National Information Infrastructure (NII) Education Forum" will be held on October 7th and 8th in Arlington Virginia. We at LBL are working with Sandia National Laboratory, Texas, to set up an MBONE link and televise portions, and hopefully the entire conference over MBONE. The router is not yet configured, but should be near lanl-mr1.es.net. The audio and video sessions are advertised in 'sd' with the following parameters: Audio 224.2.166.32, port 49051, id 0, TTL of 159, 64kbps Video 224.2.166.32, port 49240, id 0, TTL of 95, 128kbps The conference agenda is enclosed. All the times are Eastern Standard Time. *********************************************************************** *** Please let me know if there is a schedule/bandwidth conflict, or ** *** if you would like to receive it farther away. ** *********************************************************************** -Case Larsen ctlarsen@lbl.gov / Computing Resources / Lawrence Berkeley Laboratory --------------- National Information Infrastructure (NII) Education Forum. Crystal City Marriott, Arlington, Virginia (703-413-55OO) October 6-8, 1993 Draft Agenda (revised 9/2/93) Thursday, October 7,1993: 8:45am to 9:00am Welcome: A. Trivelpiece, Director, Oak Ridge National Laboratory 9:00am to 9:45am Keynote Address: Secretary O'Leary (invited) 9:45am to 1O:OOam Break lO:OOam to 11:OOam State of American Schools (readiness for technology) -Jan Hawkins, Center for Children and Tech.(30 min) -Robert Tinker, TERC (30 min) 11:00am to Noon Approaches to Learning (role of technology) -Joe Walters, Project Zero, Harvard University (30 min) -Roy Pea, Northwestern University (30 min) 1:OOpm to 2:00pm Case studies of schools and technology -Adventures in Supercomputing Experience (Sharon Carruth) -Local case study, John Kaltsas, Arlington Heights, IL school district -Students' perspectives, (NM high school student) 2:00pm to 3:00pm Overview of National Laboratories' Capabilities -Ed Oliver, Moderator for Lab presentations -Hardware and networking capability. Bill Lokke, LLNL -Software and technology capability, (TBD) -Education programs, Rich Stephens, DOE 3:00pm to 3:15 Break 3:15pm to 3:45pm Education Networking Technology Overiew -Pat Burns, Colorado State, Overview of INTERNET -Stu Loken, LBL, Workstation applications 3:45pm to 5:30pm Hands-On Demonstrations Friday, October 8, 1993: 8:l5am to 9:00am Overview of related federal activities -Nora Sabelli, NSF, NAS workshop report -Gary Johnson. DOE HPCCIT Education -Subcommitee, Report on Activities 9:00am to 10:15am Comments from Industry Participants, Sign up for Slots to discuss company, industry, etc. lO:l5am to 10:30am Break 10:30am to 12:30pm Small Group Meetings: Recommendations for DOE four groups, will discuss options for the development of education technology. 1:30pm to 2:30pm Group Reports 2:30pm to 3:00pm Summary and Closing Remarks -Dave Nelson, DOE/ER From rem-conf-request@es.net Thu Sep 30 04:01:48 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <19451-0@osi-east.es.net>; Thu, 30 Sep 1993 01:01:13 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 30 Sep 1993 09:00:16 +0100 To: luca@ibmpa.awdpa.ibm.com cc: st (ST WG Discussion List) , end2end-interest (End2End Interest) , rem-conf (Rem-Conf WG Discussion List) Subject: Re: 2 papers on ST-II In-reply-to: Your message of "Tue, 28 Sep 93 18:50:33 BST." <9309281650.AA10910@kiwi.heidelbg.ibm.com> Date: Thu, 30 Sep 93 09:00:14 +0100 From: Jon Crowcroft Luca, thanks for posting these - i ftp'd them & read them & understand where you are coming from now! >The file "st2-impl.ps" contains a paper describing our ST-II >implementation. The paper will appear on Internetwork: Research and >Experience after some minor changes. I am interested here - you say this is a user space implementation on AIX3.2 on rs6000 - what is the data link driver interface (to token ring) ? is it DLPI? i liked the performance anaalysis - quite clear.. >The file "st2-recv.ps" contains a paper describing our extensions to >ST-II for receiver-initiated communication. Please note that this is a >preliminary version. this is something that the mbone has shown has been a shortcoming of the origianal ST approach, so i am glad you have looked at fixing it! however, i am not sure about the receiver join at a router - how do they know which router to join the stream at? also, what lessons fdo you think could be drawn in general for other simplex circuit based approaches (e.g. B-ISDN/ATM) and signalling (e.g. Q.93b)? thanks jon From rem-conf-request@es.net Thu Sep 30 14:37:15 1993 Received: from ux5.lbl.gov by osi-east.es.net via ESnet SMTP service id <24974-0@osi-east.es.net>; Thu, 30 Sep 1993 11:12:33 +0000 Received: by ux5.lbl.gov (4.1/1.39) id AA20927; Thu, 30 Sep 93 11:12:14 PDT From: clarsen@ux5.lbl.gov (Case Larsen) Message-Id: <9309301812.AA20927@ux5.lbl.gov> To: David Walker Cc: KChong@uci.edu, rem-conf@es.net Reply-To: CTLarsen@lbl.gov Subject: Re: National Information Infrastructure (NII) Education Forum Announcment In-Reply-To: Your message of Thu, 30 Sep 93 10:58:44 -0800. <199309301754.AA24949@mothra.nts.uci.edu> Date: Thu, 30 Sep 93 11:12:12 PDT >I am trying to get some people interested in viewing some of the sessions >on our campus. Are the agenda times really Eastern *Standard* Time, or >Eastern *Daylight* Time? They are Eastern Daylight Time. -Case From rem-conf-request@es.net Thu Sep 30 16:48:29 1993 Received: from eitech.eit.com by osi-east.es.net via ESnet SMTP service id <27030-0@osi-east.es.net>; Thu, 30 Sep 1993 13:30:55 +0000 Received: from collage (collage.eit.com) by eit.COM (4.1/SMI-4.1) id AA02323; Thu, 30 Sep 93 13:30:47 PDT Date: Thu, 30 Sep 93 13:30:47 PDT From: vinay@eit.COM (Vinay Kumar) Message-Id: <9309302030.AA02323@eit.COM> To: mbone@isi.edu Subject: mmphone Cc: rem-conf@es.net [ I Apologize if you are seeing two copies of this mail ]. In my spare time, i wrote a simple script called "mmphone". The purspose is to facilitate users of vat/wb/nv to do Unicast point-to-point conversations, without having to use "MBONE Audio" feed ( i am not trying to advocate use of unicast over multicast, please use multicast as often as possible !). "mmphone" is a simple form-filling program for point-to-point conference call initiation and setup. To initiate a session, just type: mmphone This will send out a MIME E-Mail to the other destination site. At the receiving end, if you do not have a MIME E-Mail reader, then simply save the email message received as an ascii file and type: mmphone This will crank up appropriate wb/nv/vat tools and connect to the site that initiated the call. At the receiving side, this will also work with Bellcore's MIME parser "metamail" if the ".mailcap" is properly configured. (Instructions are in the distribution). I have found this tool fairly useful, you can use it as well by ftp'ing from: eitech.eit.com (192.100.58.2) under ~ftp/pub/share/mmphone.tar.Z Please be polite in sending your comments, bug-reports etc..to me. -- Vinay Kumar vinay@collage.eit.com From rem-conf-request@es.net Thu Sep 30 21:15:35 1993 Received: from spool.UU.NET by osi-east.es.net via ESnet SMTP service id <29449-0@osi-east.es.net>; Thu, 30 Sep 1993 18:15:02 +0000 Received: from sarad.cs.su.oz.au by spool.UU.NET with MHSnet (5.61/UUNET-uucp-primary) id AA23011; Thu, 30 Sep 93 20:17:07 -0400 Message-Id: <9310010017.AA23011@spool.UU.NET> Received: by joyce.cs.su.OZ.AU with postie; Fri, 1 Oct 1993 10:16:55 +1000 Date: Fri, 1 Oct 1993 10:12:17 +1000 From: bob@sarad.cs.su.oz.au (Bob Kummerfeld) Subject: Re: National Information Infrastructure (NII) Education Forum To: rem-conf@es.net From: clarsen@ux5.lbl.gov (Case Larsen) To: David Walker Cc: KChong@uci.edu, rem-conf@es.net Reply-To: CTLarsen@lbl.gov Subject: Re: National Information Infrastructure (NII) Education Forum Announcment Date: Thu, 30 Sep 93 11:12:12 PDT >I am trying to get some people interested in viewing some of the sessions >on our campus. Are the agenda times really Eastern *Standard* Time, or >Eastern *Daylight* Time? They are Eastern Daylight Time. -Case It would be nice if everyone posted times in BOTH local and UTC (aka GMT). Bob