From rem-conf-request@es.net Mon May 3 08:43:12 1993 X400-Received: by mta osi-west.es.net in /PRMD=ESnet/ADMD= /C=US/; Relayed; Mon, 3 May 1993 08:34:17 +0000 Date: Mon, 3 May 1993 08:34:17 +0000 X400-Originator: rem-conf-request@es.net X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=ESnet/ADMD= /C=US/;osi-west.e.517:03.04.93.15.34.17] Priority: Non-Urgent Dl-Expansion-History: rem-conf@es.net ; Mon, 3 May 1993 08:32:45 +0000; From: Erik Wilde To: rem-conf Subject: Audio/Video Conferencing using the Internet Content-Length: 1502 Status: RO X-Lines: 28 Hi there, I'm new to this list, so please excuse me if I'm asking a FAQ that you have to answer every week. Generally, I'm not looking for complete answers or descriptions but for pointers which might help me to find the information I need. So here is what I'm looking for. We have SPARCstations 10 running SunOS 4.1.3 and X (OpenWindows and MIT X) and we have no special hardware in them (in fact, we have a parallax card, but I don't want to use it, I need general solutions). There are ways to make audio and video conferencing possible using only the internet and software solutions. I recently looked at the picture phone by BBN and was amused to see a live scene from Massachusetts on my screen in Switzerland. But, as I understand, there are other solutions which use Internet multicast and which make remote conferencing possible. I'm currently looking for papers, standards, rfcs and similar things to become more knowledgeable in this area. What we want do is taking part at the JENC '93 which will be broadcast over the Internet. Therefore I need software which enables us to join such conferences. Does anybody know which software is around, what does it require and where does it run? Any help welcome, thanks in advance and best regards from Switzerland, Erik Wilde (wilde@tik.ethz.ch) Swiss Federal Institute of Technology (ETH Zuerich) Laboratory of Computer Engineering and Networks (TIK) ETH-Zentrum, ETZ G61.2, CH - 8092 Zuerich Phone: +41-1-254-7009 Fax: +41-1-251-2504 From rem-conf-request@es.net Mon May 3 11:54:24 1993 Date: Mon, 3 May 1993 11:40:59 -0700 From: schooler@ISI.EDU Posted-Date: Mon, 3 May 1993 11:40:59 -0700 To: rem-conf@es.net Subject: Re: Confctrl meeting using MBONE (Take 2) Cc: schooler@ISI.EDU, abel@thumper.bellcore.com Content-Length: 651 Status: RO X-Lines: 24 The Conference Control BOF that met at the IETF plans to hold a follow-on telemeeting over the MBONE. Date: Wednesday, May 5, 1993 Time: 0800-1000 PDT/ 1100-1300 EDT/ 1600-1800 UTC Topics for Discussion: Report on charter Revised framework Mapping of conversation styles into session protocols Terminology reference guide Refinements to functional taxonomy Participation: We will advertize the session as "Confctrl Meeting" using the LBL sd program [v1.11 or later], which in turn will invoke vat [v1.56 or later]. For detailed information about MBONE participation, see the file venera.isi.edu:mbone/faq.txt. From rem-conf-request@es.net Mon May 3 13:43:51 1993 From: wat Subject: question on CELP To: rem-conf@es.net Date: Mon, 3 May 93 15:20:38 CDT Mailer: Elm [revision: 66.36.1.2] Content-Length: 1367 Status: RO X-Lines: 42 Dear sir, I am a UW-Madison student and researching on code excited linear prediction coding (CELP). I am reading the Federal Standard 1016: Telecommunications: analog to digital conversion of radio voice by 4800 bit/sec code excited linear prediction(CELP) ---prepared by: National communications System Office of Technology & Standards ---published by: General Services Administration Office of Information Resources Management ---issue date: Feb 14, 1991 Question: On page one, the figure obviously shows that there are 256 adaptive codes in the code book. However, on page five, section3.5, it clearly describes that the adaptive "code book" is a 147 element, shifting storage register... How come the two numbers doesn't match at all? What is the actual size of the code book? Please tell me the answer. Thank you very much. tony wat <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< "You go to graduate school until you graduately don't want to go to school." ----Garp official full name: wat, sin chi (anthony) email adx: wat@cae.wisc.edu school: University of Wisconsin, Madison phone #: (608) 264-1321 "The bEd times are the good times." ----watG <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From rem-conf-request@es.net Mon May 3 15:02:42 1993 From: wat Subject: about "Dear sir," To: rem-conf@es.net Date: Mon, 3 May 93 16:56:23 CDT Mailer: Elm [revision: 66.36.1.2] Status: RO Content-Length: 137 X-Lines: 7 Dear Ladies and Gentlemen, Please forgive my rudeness. I deeply regret. Thank you to those who kindly pointed out my mistake. tony wat From rem-conf-request@es.net Wed May 5 02:57:49 1993 Posted-Date: Wed 5 May 93 02:37:07-PDT Date: Wed 5 May 93 02:37:07-PDT From: Stephen Casner Subject: AVT WG Minutes etc. To: rem-conf@es.net Mail-System-Version: Status: RO Content-Length: 24807 X-Lines: 492 To the participants in the Audio/Video Transport Working Group: This message includes the minutes of the AVT WG meetin at IETF in Columbus, along with several questions and comments on open issues discussed at that meeting. I'd like to get your feedback. The plan for producing Internet Drafts leading to RFCs is as follows. ASAP Release an updated set of drafts to replace those that have recently expired and to incorporate as much of the discussion from Columbus as possible. mid-May Release a revised version of the protocol spec with a proposed set of options to implement the security services we discussed in Columbus. June One or two revisions of the drafts to correct any deficiencies as necessary before submitting the drafts for publication as RFCs. Note that there are a couple of two-week review periods in this schedule. It is very important that your responses be timely if we are to meet the goal of submitting the drafts for RFC publication. Lack of response will be assumed to indicate concurrence! I will be on vacation for the rest of May, but I will be checking in with folks at ISI and with Henning. Assuming that we follow this schedule and produce the RFCs, the WG will have completed its initial charter. Therefore, as I stated in March and nobody raised any objections, I plan that the WG will not meet in Amsterdam. After that, depending upon the experience with the protocol, the WG may conclude and disband, resume for further protocol revision, or perhaps change the charter to move up to the next level. Thanks for your attention. Enclosed below are a list of questions and comments, followed by the minutes as submitted for the proceedings. Sorry this is a bit long; those of you who are not interested, hit 'd' now. -- Steve Casner Questions and Comments ====================== ** Removing RTCP from RTP During the IETF meeting, several people suggested that the RTCP options not directly related to transport functions be separated into another document or at least a separate section. But which options would those be? How about the QOS reverse control option? It is defined to pass its data unmodified to the application. How about the new "return address" option that will solicit QOS responses. Those return addresses could be supplied by some other higher-level control protocol. So, what should be the criterial for separation? ** Changing the name "content source" In the last meeting, it was observed that some confusion arose in the discussion because of the similarity of the options names CSRC, SSRC, CDESC, SDESC. "Content" has a somewhat different meaning in CSRC and CDESC. It was suggested that we change a name, and I suggest that the one to change would be from "content source" to "originating source". We would retain "synchronizing source" and "network source" in addition. Does that sound reasonable? (I have not made this change yet anywhere else in this message.) ** Gateways and reflectors Maybe we should review the distinction between a gateway and a reflector. Both modify the RTP header now that a reflector inserts the SSRC option, so that distinction has been eliminated. But the distinction should be on whether it does retiming or not, so the receiver knows whether to keep separate timing contexts for the streams passing through the gateway/reflector. An encoding translator need not do any retiming, and so could pass data from multiple content sources through individually on a single socket. It would NOT want to be the sync source. ** Local identifier or full address in SSRC As I reviewed Charley Kline's description and the diagrams that Ron Frederick drew up from that, I see that the SSRC contains a full address and port number. That's not what I thought it would be. Like the CSRC option, the SSRC option needs to be inserted into every data packet when the path includes a reflector, so size is still a concern even though there would be at most one SSRC in a packet. I believe Henning will propose the local identifier for the SSRC in the next draft. One issue is that to use short identifiers a reflector must keep state, which is contrary to "the multicast way". If a reflector crashes and comes back, it might cause the wrong name to be highlighted if an identifier is reused. Perhaps not, though, if the port number in the reflector's network source address could be expected to be different in which case the hosts behind it would all appear to be new entries. Might a reflector use the same output socket for more than one multicast address (e.g., with sendto())? If so, the source identifiers it generates will be shared across multiple sessions, but that may not matter because they will remain unique to the reflector's socket address as seen by each conference. ** Return addresses, passing through gateways, wrong flow number During the meeting, we talked about wanting to allow QOS messages to be processed either by a mixing gateway, which might adjust its output encoding, or to be passed all the way back to the content source so that it could make adjustments. There is a problem with this latter case because the receiver won't know the flow index that the content source used, only the flow index used for the mixed stream. ** Controlling the return of QOS information Christian suggested that we need an option to control whether QOS should be returned, and perhaps how often and from which receivers. ** Content-specific return addresses The destination for reverse control information was previously specified by a CDESC option. That bound the return address to a specific content type on the assumption that the return information in a RAD option might be different for different encodings. Is that a valid notion? Do we need to still maintain a binding to content type with the new, separate "return address" option? If we switch content types in one flow (say for flow control purposes), should there be an opportunity to switch return ports also? ** IPng return addresses Will there be case where the sender and receiver of a data stream are using different IPng systems, e.g. SIP and PIP? Or perhaps a simpler case is that one end uses some IPng, but the other only does IPv4 This is based on the assumption that all the IPng systems will have a method for interoperation with IPv4 systems. If we will have one or more of these cases, how shall we handle it? For example, if a SIP source sends a SIP address in the "return address" option to a receiver that can only do IPv4, what is the receiver to do? Is the answer that, during the "transition period", a site that wants to send an IPng address must also send an IPv4 address, assuming that all of the systems will have a way to embed IPv4 addresses? ** Mapping of local and global identifiers At the meeting, we talked about a number of tradeoffs between using local and global identifiers. Those tradeoffs are presented here for everyone to consider. Mapping of locally unique identifiers to addresses and/or names can be readily implemented with the SDESC option, but there was some reluctance to depend on the RTCP mechanism. Christian Huitema claimed that it is silly for vat, nv and ivs to all carry participant names in a session; instead, they should all be handled in common by a higher-level control protocol. And particularly in an IETF multicast, it is not necessary for all of the receivers to know about each other. But then the question arises, how do you map from the locally unique identifiers known by RTP to the names known by the higher-level protocol? The sync source is the one that knows the mapping, so it would have to participate in the higher-level protocol. That protocol might only know about the end systems. John Wroclawski suggested that a separate protocol, not using the realtime channel, could be used by the sync sources to multicast out the mappings for the local identifiers they had assigned, or that there could be a protocol defined to allow the sync sources to be queried. On the other hand, it seems that the overhead of sending the SDESC options in the realtime channel is small enough that it really may not matter that much. Christian suggested that we could avoid the local identifier problem by sending global identifiers instead, and that we could afford to use the longer global identifiers (address + port) in the data packets if we sent the CSRC and SSRC options at a reduced frequency such as every 4th packet instead of every packet. However, Ron pointed out that with reordering it gets tricky to accurately assign sources to every packet. It was then pointed out that even if the RTP options carried globally unique identifiers consisting of a network address and port, it would not be possible to look them up in the DNS because the DNS doesn't know about ports. Therefore, a higher-level control protocol would still need to be involved anyway in talking to the source entities in the system to map the global identifiers to names. However, I think there is a difference: global identifiers reference end systems directly, so the gateways are not needed to do translations as they would be for local identifiers, except that gateways would be involved in translating those global identifers that are the addresses of the gateways themselves. Is routing through gateways and reflectors assumed to be static? If not, then locally-unique identifiers will be insufficient to detect when the same source gets routed through a new path. ** HELLO option Thierry Turletti asked for a HELLO option to to solicit an immediate response of CDESC, SDESC, and/or RETURN ADDRESS options. At the meeting, Christian Huitema indicated they had decided that the HELLO was unnecessary. Actually, it might not be such a bad idea if it is defined to only cause a response from sources already sending data. It would be useful for applications that have listeners that are not senders, and so would not be sending SDESCs. Or maybe we should just say that in such applications, when a new listener comes up it should send an SDESC once to serve the same function as the HELLO. That way, the recipient of the SDESC would know more than it would with the HELLO. But one advantage of the separate HELLO option would be that it would indicate a new start even if its sender made a quick restart after an involuntary shutdown. ** Entity addressing model At the November meeting, it was suggested that we should have a model for "entity addressing" covering both the unicast and multicast cases, and including IP addresses, port numbers, and flows. Should the flow model be unidirectional or bidirectional? We've begun to define the entities (end systems, gateways, etc.), but we don't have generic terms for address and port. The spec refers here and there to multicast groups or ports, which is not accurate for ST unless we define the meaning of addresses information. Minutes of Audio/Video Transport Working Group (AVT) ==================================================== The AVT WG met for three sessions. In the first two, we discussed some open issues on the draft specification for the Real-time Transport Protocol (RTP); the third session was an "implementors agreement" session focusing on software video encoding. 1. Status of the Working Group and review of draft RTP specification The goal of the AVT WG is to specify a set of experimental protocols for real-time transmission of audio and video. The emphasis is short term to promote experimentation now so that standards-track protocols can be developed based on what we learn. The first WG meeting was a year ago, so one might expect a conclusion soon. In fact, many issues were resolved during the last two IETF meetings and the specification is nearing readiness for RFC publication. A set of four Internet Drafts specifying the RTP protocol were issued in December 1992, and an Internet Draft on packetization of H.261 coded video was issued in March, 1993. In addition, RTP has been implemented to varying degrees in the following programs: - IVS, by Thierry Turletti & Christian Huitema from INRIA - Maven, by Charley Kline from UIUC - NEVOT, by Henning Schulzrinne from UMass and AT&T Bell Labs - nv, by Ron Frederick from Xerox PARC - PicWin, by Paul Milazzo & Bob Clements from BBN (an older draft) - PVP, by Steve Casner from ISI We began this session with a brief review of RTP. It consists primarily of protocol header for real-time data packets, which is just eight octets long in the typical case. RTP supports the following functions: - transfer of media data - demultiplexing of multiple flows - content identification (e.g., the media encoding used) - synchronization and sequencing - options for simple control functions such as identification of participants Full details on the protocol are available in the Internet Drafts (see section 4). 2. Discussion of open issues There were a few open issues that had come up since the last meeting. The primary items discussed at this meeting were: - elimination of IPv4 addresses carried within RTP - separation of RTCP control functions not related to transport - security services and mechanisms These issues are expanded in the following paragraphs. No roadblocks were identified, but resolution of some of the questions was left to email discussion. The CSRC and SSRC options in the December RTP spec carried globally unique identifiers for the "content source" and "synchronization source", respectively, in data packets that have been processed through transport/application-level gateways such as audio mixers. These globally unique identifiers were based upon IPv4 addresses, but this is not acceptable considering the impending transition to a next-generation IP. Therefore, we considered two revision choices: 1. Use a (type,length,value) triple to allow any form of address to be carried. 2. Carry only a 16- or 32-bit identifier locally unique to the gateway that inserts the option, and then define the mapping to a globally unique address or other information through an extended SDESC (source description) option or a higher-layer protocol. Since the CSRC and SSRC options may be carried in every data packet for some flows, the long addresses in the first choice might impose an uncomfortably large overhead. Furthermore, we recognized that the locally unique identifier is sufficient for an RTP receiver to distinguish the source and process the packet; it is only necessary to map to a globally unique address or user name for purposes of monitoring, control, and user interface. Therefore, the second choice was selected, and it was generally agreed that 16 bits would be sufficient because the identifiers are unique only with respect to the full source address of the gateway (network address plus UDP port, for example). Mapping of the identifiers to other information, such as the name of a conference participant, should be accomplished through a higher-layer control protocol. Note that the gateway entities must be involved in that protocol, but this would be true even if globally unique addresses were used since the addresses include port numbers to allow more than one entity per host. One way to accomplish the mapping is through the Source Description (SDESC) option in the RTP control "sub-protocol", RTCP. The SDESC option includes the 16-bit identifier plus one or more items to which it is mapped. Examples include the user name, as before, and various forms of globally unique addresses. A full address must also be specified for the return of RTP reverse control packets containing options such as the Quality of Service Measurement (QOS) option. In the December draft, a return port number was specified in the Content Description (CDESC) option, but it was agreed that a full address is required because the return information may go to the content or synchronization source or to third party monitoring host. Furthermore, it was suggested that the return address be separated into its own option because it may be desirable to establish a return address without defining a new content type or redefining an old one. One problem is that the sender and receiver of the reverse control information may be using different forms of addressing, for example IPv4 and SIP or PIP. This problem extends beyond RTP, and its solution will depend upon IPng transition plans. Two solutions we have considered are to use a DNS name or to allow multiple forms of binary address to be specified. Some members of the working group objected to including within the RTP spec those RTCP options unnecessary for transport functions. However, it seems impractical to split off a few pages of RTCP option definitions into another RFC. It was agreed to keep the RTCP options within the RTP spec as a separate section with appropriate disclaimers about these functions being replaced by higher-layer control protocols when they are available. The RTP specification draft includes a brief Security Considerations section, but the protocol will be inadequate for teleconferencing applications without access to some security mechanisms at least for confidentiality of voice communication. In the future, it may be possible to depend on security mechanisms at the IP layer, but for near term use, possibly including experimentation with new security mechanisms spedifically for real-time applications, we believe it is appropriate to define security mechanisms at the RTP layer. Stuart Stubblebine of ISI made a presentation reviewing the security services and mechanisms that might be needed for applications that use RTP. The most needed services are confidentiality and integrity of the payload, and authentication of the source. Integrity is considered separately for individual packets and for the stream of packets. A set of three new RTP options was proposed to implement these security services: - ENC, to indicate the start point for encryption and carry the initialization parameters; - MIC, which may be used with a variety of security schemes, for example to carry a Message Integrity Check; and - KDEF, an RTCP option to define key identifiers. Details of these security options will be found in a new draft of the RTP spec to be released in mid-May. In addition to the major topics, we also discussed a request from Frank Hoffmann at IBM ENC for two additions to the protocol to allow higher reliability levels of service. The first was that a checksum option be provided for use when RTP is carried over ST-II, which does not provide a checksum. However, there is a problem with carrying a checksum in an option: an error in the header may make it appear that there is no checksum option, so the checksum would not be checked and the error would not be detected. Also, it is inconvenient that an RTP-level reflector from ST-II to IP/UDP would have to check and remove the checksum option to avoid presenting the UDP destination with two potentially conflicting checksums. As an alternative, it is suggested that there be a separate specification for an encapsulation of RTP in ST-II that would include a checksum. That encapsulation might define a service like that of UDP over IP. The second request was for an option to request retransmission to implement a "reliable" class of service. It is expected that most real-time applications will not want to incur the delay imposed by retransmission. A generic retransmission function probably does not make sense in RTP, but reverse control options can be used to request retransmission in an application-specific manner when appropriate. For example, negative acknowledgements are defined in the INRIA H.261 packetization protocol draft. For those applications that want to use the services of RTP but do require reliable delivery, RTP can be transported in a TCP stream. One final topic that we did not have time to discuss adequately was how RTP profiles should be defined and used. Would it be reasonable to include as part of a profile definition that the RTP framing field would always be included in order to allow multiple RTP PDUs to be assembled into, for example, one UDP packet? We have also not defined how the selection of a particular profile will be identified for applications that can operate with more than one profile. More work is needed on this topic. 3. "Implementors agreement" session We devoted the third WG session to an "implementors agreement" discussion to promote convergence and interoperation among the software video compression programs being developed. At the previous meeting, it was observed that the tight coupling between the video frame grabbing procedure and the encoding process might mean that it would be infeasible to define an API between these two steps. However, Ron Frederick has observed that the coupling between software decoding and the display process can be much more flexible. Therefore, it may be feasible to achieve interoperation by allowing each hardware and software platform to encode and transmit data in its native format, but to incorporate multiple decode routines using a common API so that each program can decode many or all of the other programs' native formats. Ron Frederick gave a presentation on the implementation of a decoder API in version 3.0 of the "nv" program. Decoding and rendering of the image data and decoupled: nv does all the network I/O, RTP processing, and X window system interaction; the image decode routines just convert each packet of compressed bits into uncompressed pixels for a portion of the image. When the "S" bit (end of synchronization unit) is set in the RTP header, nv will display the new image on the screen. This scheme allows support for multiple display depths, brightness/contrast mapping, and image scaling with simultaneous display of multiple sizes. Three decoders have been incorporated into nv to process video from nv, from the hardware Bolter codec, and from the Cornell CU-SeeMe program. Christian Huitema identified a problem with the nv API when he described the H.261 encoding in the IVS program and the complexity that results from a combination of image structure and Huffman encoding of the image coefficients. There is a lot of state information implicit in the decoding process in the middle of processing "group of blocks" (GOB). Since one GOB may occupy more than one packet, it might be infeasible to try to save and restore the state at the boundary between packets so that control could be returned across the API from a decode routine. Therefore, IVS uses the "S" bit to indicate the GOB boundary so that all of the packets of a GOB can be handed together to the decode routine. This conflict in the interpretation of the S bit will have to be resolved to allow interoperation of nv and IVS. It was suggested that IVS is using the S bit for a transport function, whereas nv is using it for a presentation function, and therefore the former is correct. Ron said nv could be modified to get the display-image indication as a return valued from the decode routine, so this may be the solution. Paul Milazzo has implemented color video transmission in the BBN PictureWindow program. Paul proposed that the YCrCb color encoding from the CCIR 601 digital video standard be used as the color representation for software encoding. This is similar to the YUV analog encoding. The proposed scheme would keep the luminance (Y) pixels in one array, and chrominance (CrCb or UV) pixel pairs, subsampled by 2 in the X dimension, in another array. Because of the subsampling, the two arrays would be the same size. This scheme allows easy rendering into monochrome or color images. 4. Further WG activities A set of Internet Drafts on RTP was issued in December 1992: draft-ietf-avt-rtp-00.txt draft-ietf-avt-encoding-00.txt draft-ietf-avt-profile-00.txt draft-ietf-avt-issues-00.ps, .txt The first draft is the specification of the real-time transport protocol itself. The second and third drafts define a set of media encodings and a sample profile for use of those encodings to implement audio and video multiparticipant conferences with minimal control. The last draft is an updated discussion of the issues and decisions involved in the design of the protocol. Revised drafts incorporating changes discussed at this meeting will be issued in May. After review and possible further revision, it is expected that the drafts will be submitted to become RFCs in June, completing the working group's charter. [end] ------- From rem-conf-request@es.net Wed May 5 10:25:11 1993 From: vincent@tesla.gport.com (vincent bilotta) Subject: joining mbone conferences? To: rem-conf@es.net Date: Wed, 5 May 1993 13:08:27 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 376 Status: RO X-Lines: 11 Hello, I would like to hook in, my host is tesla.gport.com 198.6.128.10 the other end of the tunnel is 153.39.128.104 (Alternet) what else do i need to do? sit by my screen with sd running? look for IETF announcements? If i wanted to use th MBONE for a packet film showing, on a saturday night what is the proper way to clear this? all opinions would be appreciated, vincent From rem-conf-request@es.net Thu May 6 08:29:56 1993 Date: Thu, 6 May 93 11:12:02 EDT From: chang@muon.nist.gov (Wo_Chang_x3439) To: rem-conf@es.net Subject: Vice President Gore on packet video (May 5, 1992) ??? Cc: chang@muon.nist.gov Status: RO Content-Length: 380 X-Lines: 11 I heard from people saying that Vice President Gore will address HPCC tomorrow, May 7, 1993 on somekind of packet video, is there anybody on the Internet will broadcast that over the MBONE? Another question: how do you go about to record audio and video onto VCR or may be even to disk? Any pointer would be greatly appreciated. --Wo Chang From rem-conf-request@es.net Thu May 6 10:44:58 1993 Posted-Date: Thu 6 May 93 10:30:12-PDT Date: Thu 6 May 93 10:30:12-PDT From: Stephen Casner Subject: Re: Vice President Gore on packet video (May 5, 1992) ??? To: chang@muon.nist.gov, rem-conf@es.net Mail-System-Version: Status: RO Content-Length: 263 X-Lines: 8 The HPCC event will be multicast over the MBONE, and will be advertised in sd. Matt Mathis sent the announcement message to the mbone and ietf lists, but not rem-conf. Matt, I suggest that you send the announcement to rem-conf as well. -- Steve ------- From rem-conf-request@es.net Thu May 6 11:26:46 1993 Posted-Date: Thu 6 May 93 11:07:48-PDT Date: Thu 6 May 93 11:07:48-PDT From: Stephen Casner Subject: Re: joining mbone conferences? To: vincent@tesla.gport.com, rem-conf@es.net Mail-System-Version: Status: RO Content-Length: 1176 X-Lines: 30 Vincent, Sorry for the delay in answering your earlier private message; I'm trying to get everything done that I need to before leaving momentarily to go on vacation. I expect that transmitting a film on Saturday night would not cause any overload, since the MBONE is likely to be quiet then. But it also means that the potential audience will be small. My guess is that people would ask to retransmit during the week, and then to increase the programming, ... I'm not saying you shouldn't do it, but it will have to be carefully managed, in the same way that I'm hoping to keep a lid on radio broadcasts by the "Please don't" pseudo-session that I'm advertising in sd. But a big question is copyright. Radio Free Vat is probably not legal, either. > what else do i need to do? > sit by my screen with sd running? That's about it. Do you see a bunch of sessions in sd? If not, your tunnel is not working yet. > If i wanted to use th MBONE for a packet film showing, > on a saturday night what is the proper way to clear this? Nobody is in control (its distributed and based on honor), though I try to lend a guiding hand as much as I can. -- Steve ------- From rem-conf-request@es.net Thu May 6 12:13:17 1993 To: rem-conf@es.net Subject: Mbone transmission of Conference on Grand Challenges - Friday May 7 Date: Thu, 06 May 93 14:52:57 -0400 From: Gwendolyn Huntoon Status: RO Content-Length: 2215 X-Lines: 87 Mbone transmission of the Conference on Grand Challenges for High Performance Computing Friday May 7, 1993 8:00 AM - 5:00 PM Conference Objective: Promote dialogue and interaction among leaders in the multi-sector United States high performance computing community. - ---------------------------------------------------------------- MBone information: If you have "sd" select "Grand Challenges for HPC" Otherwise: Audio: vat -n 224.2.140.130/40466/58266 Video: nv 224.2.140.130 63353 The audio and video will be transmitted at TTL=127. Video will be transmitted with nv 3.1 at 128 kb/S for most sessions. Gore's keynote address and perhaps other presentations will be transmitted at a higher rate, TTL to be determined. There will also be a "GC for HPC Control" session to reach the Mbone transmission desk. We will be testing during the day Thursday. If you have problems or questions about the mbone transmission ONLY please send mail to pscnet-admin@psc.edu. Control: vat -n 224.2.140.130/53689/56105 - ---------------------------------------------------------------- Schedule: 8:00 - 8:10 Welcome and Introductions (Paul Smith) 8:10 - 9:10 Summary Reports from Applications Panels * Environmental and Earth Sciences * Computational Physics * Computational Biology, Chemistry and Material Science * Computational Fluid and Plasma Dynamics * Applications of Artificial Intelligence 9:10 - 10:10 Reports from Working Groups 10:10 - 10:30 Break 10:30 - 12:35 Reports from Working Groups 12:35 - 1:30 Lunch 1:30 - 2:10 Reports from Working Groups 2:10 - 2:45 Keynote Address, Vice President Gore 2:45 - 3:10 Reports from Working Groups 3:10 - 3:30 Break 3:30 - 5:00 Industrial Applications Panel 5:00 Adjourn Working Group Reports * I/O, Data Systems and File Systems for Software Technology * Parallel Programming Paradigms * HPC Performance Evaluation * Multidiscplinary Applications * Alogrithms and Libraries * Graphics and Visulaization * National HPCC Infrastructure Panel on Industrial Applications * Aeronautics * Automotive * Financial * Health Care * Manufacturing * Petroleum ------- End of Forwarded Message From rem-conf-request@es.net Thu May 6 17:21:12 1993 To: rem-conf@es.net Subject: mrouted on sun4 arch Date: Thu, 06 May 1993 17:04:53 -0700 From: "Danny J. Mitzel" Status: RO Content-Length: 378 X-Lines: 8 I have access to a Sun 4/300 (SunOS 4.1.3, object distribution) I'd like to use as an mrouter to the Internet. The IP multicast code only includes sun4c and sun4m object files. Is it possible to use either of these with the sun4 architecture; alternatively could someone that built from source send me the required .o's? thanks for any help! danny (dmitzel@whitney.hitc.com) From rem-conf-request@es.net Fri May 7 06:00:02 1993 Date: Fri, 7 May 93 08:47:06 EDT From: chang@muon.nist.gov (Wo_Chang_x3439) To: rem-conf@es.net Subject: HPC conference Cc: chang@muon.nist.gov Status: RO Content-Length: 358 X-Lines: 11 Is HPC conference broadcasting now? I do see the "Grand Challenges for HPC" on my sd, but there is nothing yet. According to the agenda, it should started 8:00 am EDT, is there any change on the agenda? (The last thing I heard about the broadcast will not begin till 1:45pm - 3:00pm, is this correct?) Thanks for any help. --Wo Chang From rem-conf-request@es.net Fri May 7 13:46:16 1993 To: mbone@isi.edu, rem-conf@es.net Subject: MV TTL Date: Fri, 07 May 93 16:31:05 -0400 From: Gwendolyn Huntoon Status: RO Content-Length: 176 X-Lines: 8 Please set MV TTL metrics to 2 for those of you currently watching the HPC Conference Broadcast. MV seems to be having a problem with the number of receivers. Thanks, Wendy From rem-conf-request@es.net Mon May 10 05:44:27 1993 To: rem-conf@es.net Subject: NEW FTP SERVER FOR IVS 3.1 Date: Mon, 10 May 93 14:27:17 +0200 From: Walid Dabbous Content-Length: 222 Status: RO X-Lines: 13 You can retrieve the 3.1 version of IVS by anonymous ftp from babar.inria.fr directory: pub/rodeo file: ivs3.1a.tar.Z The avahi.inria.fr server is out of service for a while Walid Dabbous INRIA Sophia Antipolis From rem-conf-request@es.net Mon May 10 06:18:15 1993 Date: Mon, 10 May 93 08:55:56 EDT From: gstewart@kestrel.lerc.nasa.gov (Gary Stewart) To: rem-conf@es.net Subject: Need ivs 3.1 for JENC. Content-Length: 735 Status: RO X-Lines: 29 I'm attempting an anonymous ftp connection to avahi.inria.fr for the 3.1 version of ivs for the JENC conference and the anonymous ftp appears to be broken: kestrel{gstewart}319: ftp avahi.inria.fr Connected to avahi.inria.fr. 220 avahi FTP server (NEWS-OS Release 4.0C) ready. Name (avahi.inria.fr:gstewart): anonymous 331 Guest login ok, send ident as password. Password: 530 User ftp: can't change directory to /u/babar/1/koala/ftp. ^^^^^^^^^^^^^^^^^^^^ Login failed. ftp> quit 221 Goodbye. kestrel{gstewart}320: Does anyone ivs 3.1 they can make available via anonymous ftp? Thanks for your help. -Gary -- Gary Stewart gary@lerc.nasa.gov (216) 433-8577 From rem-conf-request@es.net Mon May 10 06:43:35 1993 Date: Mon, 10 May 1993 09:16:41 -0400 From: Ken Hays To: rem-conf@es.net, mbone@isi.edu Subject: locale for "ivs" package ? Reply-To: Ken Hays Content-Length: 353 Status: RO X-Lines: 12 Hi folks, Sorry to trouble the lists with this, but - Does anybody know of an ftp site other than avahi.inria.fr to get the ivs package? The ftp server on is not letting anonymous attain "signed-on" status since the attempt to cd fails. Thought I wanted to watch the Joint European Networking Conference, but need to get the ivs tool. Thanks, Ken From rem-conf-request@es.net Tue May 11 02:53:17 1993 To: rem-conf@es.net Subject: IVS 3.1 SOURCES and BINARIES new ftp server. Date: Tue, 11 May 93 11:39:35 +0200 From: Walid Dabbous Content-Length: 468 Status: RO X-Lines: 17 IVS 3.1 sources and binaries for sun, dec, and sgi are available by anonymous ftp from host: babar.inria.fr, directory: pub/rodeo. You will find these files: -rw-r--r-- 1 dabbous 2177687 May 11 09:29 ivs-bin-sgi.tar.Z -rw-r--r-- 1 dabbous 4079673 May 11 09:31 ivs-dec.tar.Z -rw-r--r-- 1 dabbous 342687 May 11 09:32 ivs-src.tar.Z -rw-r--r-- 1 dabbous 669328 May 11 09:31 ivs-sun4-vfc.tar.Z The other server avahi.inria.fr is down... Walid Dabbous From rem-conf-request@es.net Tue May 11 08:21:40 1993 X400-Received: by mta osi-west.es.net in /PRMD=ESnet/ADMD= /C=US/; Relayed; Tue, 11 May 1993 08:01:08 +0000 Date: Tue, 11 May 1993 08:01:08 +0000 X400-Originator: rem-conf-request@es.net X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=ESnet/ADMD= /C=US/;osi-west.e.480:11.04.93.15.01.08] Priority: Non-Urgent Dl-Expansion-History: rem-conf@es.net ; Tue, 11 May 1993 07:59:36 +0000; From: Erik Wilde To: rem-conf , mbone-eu Subject: joining the mbone (repost) Importance: High Content-Length: 1378 Status: RO X-Lines: 32 I'm reposting the following message because no-one answered last time. Is there nobody responsible or at least knowledgable how I can join the mbone? Please mail me! ========================================= Hello there, today I spent my time installing the multicast extensions on my SPARCstation running 4.1.3 and now I think I finally succeeded in setting up a mrouted machine. Now I have some questions for this list: 1) I put a mrouted command into /etc/rc and copied mrouted and mrouted.conf to /etc. What else must I do to make the mrouted running (the mrouted.conf is currently empty)? 2) How can I join the mbone, i.e. set up a tunnel to another mrouted machine which then can send multicast packets to my machine? 3) Having joined the mbone, can I switch on and off the tunnel, depending on whether I am willing to give away the bandwidth which is necessary for the transmission of audio and video? 4) Which software can I use (I have vat, nv and sd, which looks really weird to me) and which conferences can I receive? I could not find the dvcrx software described in the FAQ file. Thanks for all answers, Erik Wilde (wilde@tik.ethz.ch) Swiss Federal Institute of Technology (ETH Zuerich) Laboratory of Computer Engineering and Networks (TIK) ETH-Zentrum, ETZ G61.2, CH - 8092 Zuerich Phone: +41-1-254-7009 Fax: +41-1-251-2504 From rem-conf-request@es.net Tue May 11 19:18:03 1993 To: rem-conf@es.net Subject: cheap multicast/video/audio platforms Date: Wed, 12 May 1993 12:05:36 +1000 From: George Michaelson Sender: G.Michaelson@cc.uq.oz.au Content-Length: 473 Status: RO X-Lines: 15 I've been quoted: 2xSunIPC,VideoPix,16"colour,200Mbdisk/24Mbmemory $18000 2xDEC5000/25/PiP/TX/424Mbdisk/24Mbmemory/cdplayer$30000 2xIrisIndigo,IrisVideo,24Mb $36000 The sun is 1/2 speed of the others. The DEC video is slow and nasty. the Iris is the nicest box of the lot to use. Does anybody have comments on choosing cheap platforms to demo vat/nv/multicast on? In particular, can an IPC do 4-5 frames/second with NV and do the audio at the same time? -George From rem-conf-request@es.net Wed May 12 10:45:45 1993 Date: Wed, 12 May 93 10:30:57 PDT From: ari@es.net (Ari Ollikainen) To: rem-conf@es.net Subject: Video clips from InternetMonthlyReport Cc: dvtf@es.net Content-Length: 7544 Status: RO X-Lines: 160 As is my custom, here are some relevant items extracted from the April1993 Internet Monthly Report, posted as a public service for those who might not otherwise get, read, or notice... BOLT BERANEK AND NEWMAN INC. ---------------------------- ... Real-time Multicast Communications and Applications We are currently implementing the shared streams service, using the Fair Share resource reservation code as a basis for resource enforcement. An initial version of Resource Coordination Objects (RCOs) is being designed and implemented to support user-level reservation for shared streams. We are also looking at additional applications for the four real- time multicast services in this project (anycasting, multi-level flows, shared streams, RCOs). One possibility is the use of RCOs for network-wide resource reservation, a need that has become apparent in some DARTnet experiments. During the month of March, we also worked on improvements to the video server in two areas. First, we substantially improved the interface between the workstations that control the Parallax codecs used to convert analog video to digital video, transmit the digital video across a wide area network, and receive and display the video in a window on a workstation. This work provides the basis for two new capabilities. First, the video server can make use of multicast communications to support multiple people viewing the same video simultaneously. In earlier versions of the video server, if multiple people requested the same video, a separate unicast data connection was initiated for each user. In the new version of the video server, if a user requests the same video (for example, a broadcast channel) as is being transmitted to another user, then the initial unicast data connection is broken and a multicast data connection is established to the two or more users who have requested the same video. Second, multicast digital video streams can now be broken into multi-level (i.e. multi-bandwidth) encodings. The multi-level data stream capability will allow multiple users to receive the same video stream over different bandwidth connections; one user may receive a high quality, high bandwidth video stream over high bandwidth network connections, while another user can simultaneously view the same video at a lower quality over lower bandwidth network connections. One network mechanism that can be used to support this work is the multi-level flows communications service that we are developing as part of this project. In the past month, we have also made improvements to the video catalog service, a distributed service which catalogs text information used to index video. In earlier versions of the video server, the host name of all video catalogs was stored at a well known host, referred to as the catalog of catalogs. The video applications used unicast communications to contact the catalog of catalogs and obtain the names of hosts that contained video catalogs. In the new catalog service, workstations that contain video catalogs join the video catalog multicast group; thus, the information as to where video catalogs are located resides with the servers and not with the applications. Applications send queries to locate video information directly to a video catalog multicast address and the applications receive responses from all servers that contain video information relevant to the request. The use of multicast for this service provides an important capability for wide area video information servers. The multicast capability allows video server sites to change the machines hosting catalog services, and it allows sites to add and remove video servers (and their associated catalogs) without having to modify video applications and without having to update a centralized database of video service locations. (See January '93 and March '93 Internet Monthly Reports for more details about the application and communications services being developed.) ... Karen Seo ISI --- ... MULTIMEDIA CONFERENCING This month, the Real-time Tranport Protocol (RTP) was integrated into PVP, ISI's packet video program. Now implemented in several real-time packet audio and video programs, RTP has allowed interoperation among different implementations of these tools. A parameter -N was added to PVP to allow a name to be transmitted in the RTP protocol so nv will display it when PVP and nv interoperate. In addition, enhancements were made to PVP to make it more readily configurable to work with a Bolter codec or a PictureTel codec. Steve Casner gave a talk "Internet Video -- Meltdown or the Next Email?" at the National Net '93 conference in Washington, D.C. Eve Schooler, Steve Casner (schooler@isi.edu, casner@isi.edu) OARNET ------ IETF Meeting in Late March .... In keeping with the IETF tradition, all the plenaries, and at least two of each session was simulcast to the Internet using packet audio and video. Cameras and a VCR for this purpose were donated by the Ohio Visualisation Laboratory. To provide reliable access, LCI International, and Ohio Bell telephone company donated a total of 3 T1 circuits for the IETF. One of the T1s was used to carry multicast traffic for the simulcast exclusively, and connected the terminal room directly to the OARnet POP at Cleveland, while another one carried unicast traffic from the terminal room to the nearest OARnet backbone POP; the third T1 was used to interconnect the OARnet POP at Cleveland to the ANS POP at North Royalton. At peak periods, OARnet offered approximately 400Kb/sec of IETF audio and video traffic to the ANS backbone and about 100Kb/sec of IETF terminal room traffic, or about 500Kb/sec in total. ... Ashley Burns UCL ---- 1. The INRIA Video Conferencing System Software has been merged with our CODEC software so we can now generate video from a sparc or SGI and send over IP (multicast) and receive, encapsulate in H.221 (with CRCs!) and hand to a CODEC, and vice versa. Currently, this is working at 64kbps and 128 kbps - we will move to higher speeds as and when. 2. We hosted one of the schools for the Global Schoolhouse Project's first video class over the Internet on April the 26th succesfully (after a number of successful demos where the first hop was running over our campus FDDI, on the day, this broke and we had to fallbacvk to a copper voicegrade line (driven at 256kbps!) from UCL to the UK international gateway with some clever last minute re-routing. Details reports no doubt will appear elsewhere. Many thanks to the Cornell people for introducing us to CUSeeMe (yet another neat conferencing program!). J Crowcroft now knows more about MACs than he cares to admit. 3. We hosted the first SuperJANET demonstration day on te 28th - as reported before, this net is now being bought up, and many high speed applications were shown to the various sponsors. John Crowcroft (j.crowcroft@CS.UCL.AC.UK) From rem-conf-request@es.net Wed May 12 17:31:26 1993 To: rem-conf@es.net Subject: cheap platforms for multicasting Date: Thu, 13 May 1993 10:18:51 +1000 From: George Michaelson Sender: G.Michaelson@cc.uq.oz.au Content-Length: 1339 Status: RO X-Lines: 27 I'd like to thank all the respondants. a formal summary is inappropriate given some anonymous and confidential replies. An IPC (or pair of them) will work, Albiet at a lower framerate (2-3 fps) and only if little or nothing else is done. Ivs s/w codec overheads are definately worse than nv, and will show (no criticism of the authors intended) More than 2 ivs streams on a low end platform is probably not going to look good. Sun recommend getting as much memory as possible: 8Mb is really not it. 16" screens are a bummer long-term. Some Suns will do VGA feed, we'll be splitting the RGB+Sync to a SONY projector for at least one side. With our baroque purchasing methodology, I think we'll by low-end boxes and pay more next year to upgrade them. Buying faster up-front would be cheaper overall but it seems to hurt the suits vest-pocket less to be hit twice for smaller sums. Good things are around the corner from all of the suppliers, PC and Mac included. I think re-assessing a purchase in 6 months or a year would be viable if you don't need to move on this quickly. If you do, then get as much money as you can, and consider getting just one station, relying on the mbone for the other end. Then you can go for a bigger/faster CPU, or an Italian designer CPUcase, or even both. Thanks for collective wisdom! -George From rem-conf-request@es.net Thu May 13 14:50:21 1993 Date: Thu, 13 May 1993 21:36:02 GMT From: GERMAIN@CDHF1.GSFC.NASA.GOV.\(\) (Andy Germain - \(301\) 572-1254) Subject: RTP comments To: rem-conf@es.net, DesJardi@boa.GSFC.NASA.GOV X-Vmsmail-To: SMTP%"rem-conf@es.net" Status: RO Content-Length: 1472 X-Lines: 34 My comment on the RTP Internet Draft (5/6/93) deals basically with the appropriateness of the name, "Real Time Data Transfer Protocol". It appears to me that RTP is really designed around Audio, Video, and Conferencing applications (while others are not completely ruled out). While these applications do have real-time aspects, there are other types of real time applications which have significantly different characteristics, and which do not seem to be addressed by RTP. For example, the EOS project at NASA is considering various protocols for use in spacecraft command and control applications. This application can reasonably be considered real-time: the spacecraft is only in contact with the control center for short intervals. In this application, there is therefore a maximum delay which can be tolerated waiting for a packet -- usually a fairly short time. On the other hand, some delay is tolerable, allowing for the possibility of retransmission of lost packets. Since some amount of lost packets can also be tolerated, there is an application-dependent optimum tradeoff between packet delay and packet loss. It was not clear to me that RTP would be applicable for this type of service. I am also not sure how RTP would fit it with other real-time control applications. Therefore, I wonder if the name RTP should be further qualified to more clearly indicate the uses to which it is suitable. Thanks for your interest. Andy Germain From rem-conf-request@es.net Fri May 14 19:10:38 1993 Date: Fri, 14 May 93 18:58:54 PDT From: ari@es.net (Ari Ollikainen) To: rem-conf@es.net Subject: RTP comments Cc: GERMAIN@cdhf1.gsfc.nasa.gov Content-Length: 2332 Status: RO X-Lines: 57 Most of you might not have received the following message due to it being rejected by mail gateways for an unparseable From line. After cleaning out all the "unable to deliver mail" messages from mailer-Agent/DAEMONs/postmasters and the like, here's Andy's original message: [WARNING TO ANDY... DO NOT, REPEAT, DO NOT REPLY TO ANY MAIL ON THIS LIST WITH THE HACKED FROM LINE !!! You might have learned of your mistake from all the mail sent back to you, already...Just don't do it again.] ----- Begin Included Message ----- >From rem-conf-request@es.net Thu May 13 14:50:21 1993 Date: Thu, 13 May 1993 21:36:02 GMT >From: GERMAIN@CDHF1.GSFC.NASA.GOV.\(\) (Andy Germain - \(301\) 572-1254) Subject: RTP comments To: rem-conf@es.net, DesJardi@boa.GSFC.NASA.GOV X-Vmsmail-To: SMTP%"rem-conf@es.net" Content-Length: 1472 My comment on the RTP Internet Draft (5/6/93) deals basically with the appropriateness of the name, "Real Time Data Transfer Protocol". It appears to me that RTP is really designed around Audio, Video, and Conferencing applications (while others are not completely ruled out). While these applications do have real-time aspects, there are other types of real time applications which have significantly different characteristics, and which do not seem to be addressed by RTP. For example, the EOS project at NASA is considering various protocols for use in spacecraft command and control applications. This application can reasonably be considered real-time: the spacecraft is only in contact with the control center for short intervals. In this application, there is therefore a maximum delay which can be tolerated waiting for a packet -- usually a fairly short time. On the other hand, some delay is tolerable, allowing for the possibility of retransmission of lost packets. Since some amount of lost packets can also be tolerated, there is an application-dependent optimum tradeoff between packet delay and packet loss. It was not clear to me that RTP would be applicable for this type of service. I am also not sure how RTP would fit it with other real-time control applications. Therefore, I wonder if the name RTP should be further qualified to more clearly indicate the uses to which it is suitable. Thanks for your interest. Andy Germain ----- End Included Message ----- From rem-conf-request@es.net Mon May 17 05:37:36 1993 Date: Mon, 17 May 93 08:27:38 EDT From: carl@malamud.com (Carl Malamud) To: rem-conf@es.net Subject: NPR meets the Internet Org: Internet Talk Radio Content-Length: 2464 Status: RO X-Lines: 52 Station: Internet Multicasting Service Channel: Internet Town Hall Program: National Public Radio meets the Internet Release: May 21, 1993, 2-3PM EDT Content: Talk of the Nation/Science Friday On May 21, we will be joining the Internet to National Public Radio for a special edition of Talk of the Nation/Science Friday. Host Ira Flatow will field questions from users sitting in front of computers as well as users sitting next to telephones. Questions from the Internet will come from videoconferencing tools on the Multicast Backbone (MBONE) using a gateway provided by Ron Fredrick and Steve Deering of Xerox PARC. (If you don't have MBONE connectivity now, you probably won't have it by Friday. To learn more about the multicast backbone, ftp to isi.edu and get the file /mbone/faq.txt. If you do have MBONE connectivity, check SD for a listing for Internet Town Hall.) In addition to the audio link, we will have two other ways to participate. First, starting now, you can send mail to ira@radio.com with your comments and questions. Some of this mail may be read as part of the show. We encourage you to narrow your your comments to the subject of the Internet, how it is used, and the future of networking in the western world. Second, with the help of Rick Gates, we will be conducting an Internet Treasure Hunt and reading the results over the air. The purpose of the hunt is to illustrate the diversity of methods and data available on the network. The questions will be posted on the network 24 hours before the show and will be read by Ira Flatow at the beginning of the show. Even if you don't participate with a computer for this show, we hope you will listen to your local National Public Radio affiliate. Guests will include Carl Malamud, Brewster Kahle, and Tim O'Reilly. For those of you that have computers but no NPR affiliate, we will tape the show and send it out as an audio file approximately 48 hours after it airs. Participants in the Internet Town Hall include Cornell University, the National Press Club, the National Science Foundation, O'Reilly & Associates, Sun Microsystems, WAIS, Inc., Xerox PARC, and many others. Network connectivity for the Internet Town Hall is provided by UUNET Technologies. For information on Internet Talk Radio, write to info@radio.com. More information on Internet Town Hall will be available shortly. For a current, partial listing of sites, write to sites@radio.com. From rem-conf-request@es.net Mon May 17 08:50:13 1993 To: rem-conf@es.net Address: Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Phone: 412 268 6512 Subject: mrouted problem Date: Fri, 07 May 93 08:55:45 EDT From: "H. Scott Matthews" Content-Length: 308 Status: RO X-Lines: 12 Hi I hadnt fired up the vmtp stuff for awhile, and was trying to join the GC for HPC conference. ANyway, mrouted is giving me the message: May 7 08:43:33 gx mrouted[25011]: can't enable DVMRP routing in kernel: Address already in use what does this mean? Is my tunnel from PSCnet down?? thanks scott From rem-conf-request@es.net Thu May 20 16:14:28 1993 From: vincent@tesla.gport.com (vincent bilotta) Subject: Saturday nite moviecast To: rem-conf@es.net Date: Thu, 20 May 1993 19:03:38 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2041 Status: RO X-Lines: 57 The feature-length film by David Blair "WAX or the discovery of television among the bees" (85:00) will be "broadcast" across the Internet on Saturday, May 22nd at 8:30 PM EDT Tech details: Multicast of Wax Saturday May 22nd at 8:30 EDT The session will be set up with SD version 1.14 TTL 127 audio port 63440 ID 20968 video port 38877 ID 30041 As usual, following are some quotes, to warm you up David Byrne (musician): "Here's a film that defies easy categorization, yet seems to make perfect sense, given its' own peculiar form of logic. It's logic from a world that is strangely similar to our own, a parallel universe on our own planet. It's a world that is strange, wonderful, and awe-inspiring to inhabit. A place where the present and the future interpenetrate each other in organic ways that almost feel like a new kind of sex." William Gibson (author, Neuromancer, Count Zero, etc.): "Authentically peculiar. Like something from the network vaults of an alternate universe." Iceshirt", "The Rainbow Stories", all Penguin/Viking Press) "I admire your dark and paranoid visions in all of their intergalactic complexity." Larry McCaffery (editor, "Storming the Reality Studio: A Casebook on Cyberpunk and Postmodern Fiction", Duke University Press): "WAX strikes me as a truly major accomplishment, intellectually rich, verbally inventive, visually stunning, and -- perhaps most remarkable of all -- as emotionally resonant as any film I've come across in recent years." Brooks Landon (author, "Aesthetics of Ambivalence: Rethinking SF Film in the Age of Electronic (Re)Production", Greenwood Press) "WAX is like no movie you have ever seen. Call it postmodern, postcyberpunk... or post cinema, the point is this 85 minute celebration of the possibilities of "electronic cinema" may well indicate the future direction of SF film, if not "film" itself. Timothy Leary: "WAX is a treat for the eyeballs, a delight for the receptor sites, a brilliant illumination for our left brains and our right brains!" From rem-conf-request@es.net Thu May 20 18:21:01 1993 Date: Thu, 20 May 1993 18:07:46 PDT Sender: Ron Frederick From: Ron Frederick To: rem-conf@es.net, mbone@isi.edu, ietf@cnri.reston.va.us Subject: More info on Friday NPR "Talk of the Nation" broadcast Content-Length: 3722 Status: RO X-Lines: 83 Tomrrow, Friday May 21st, at 2:00pm Eastern (11:00am Pacific, 1800 GMT) we're going to be broadcasting the National Public Radio show "Talk of the Nation / Science Friday" out to the MBONE. Guests include Carl Malamud, Brewster Kahle, and Tim O'Reilly, with the topic being the Internet, how it is used, and the future of computer networking. Questions will also be fielded from the Internet during the show. People from outside of the continental U.S. are especially welcome, as it really stresses just how big the Internet is... In order to listen, you'll need a working MBONE tunnel and a vat compatible audio tool. Look for an 'sd' session named "Internet Town Hall." For those without sd, here's the session info: Internet Town Hall NPR "Talk of the Nation/Science Friday" program about the Internet. Address: 224.2.235.24, ttl 191 Media: vat pcm audio, port 45551, conf id 48217 If you'd like to direct a question to the program, things get a bit hairier. You'll need to look for two other sd sessions -- one labelled "Internet Town Hall Questions" and the other labelled "ITH -- Invitation Only." The session info for these is: Internet Town Hall Questions Address: 224.2.235.25, ttl 191 Media: vat pcm audio, port 45552, conf id 48218 ITH -- Invitation Only Address: 224.2.235.26, ttl 191 Media: vat pcm audio, port 45553, conf id 48219 The protocol for asking a question is as follows: 1) Open the "Internet Town Hall Questions" session from sd. You'll need to quit or deactivate the regular "Internet Town Hall" session to speak there. 2) When you join the "Internet Town Hall Questions" session, wait for a quiet moment and let Steve Deering (the Question Coordinator) know that you're around and interested in speaking on the show. He'll ask for your name, location, and the nature of your question. If he's able to hear you ok, he'll tell you to go ahead to step 3. 3) If you can be reasonably well heard at PARC, you will be told to quit your existing "Internet Town Hall" and "Internet Town Hall Questions" sessions and join "ITH -- Invitation Only." Once you've successfully done so, your name will be passed to the director of the show in New York to be put on the list of waiting callers. In this new session, you'll be able to hear the program, and should wait for the host to call your name, and then unmute your mike and go ahead. Hints for improving audio quality: * Use headphones if at ALL possible! They'll prevent unwanted echo, and allow a full duplex conversation between you and the host. * If you can't use headphones, make SURE that you are in "Speakerphone" mode, so that your microphone won't pick up & send what's coming out of your speakers. * Try and keep your microphone as far away as possible from fans and other sources of noise. Keep your mike muted except when you actually wish to speak. You should use 'vat' to do this, rather than switching your mike on & off, as powering up a mike typically causes a loud and annoying click. * If you have adjusted your microphone volume by hand, remember to set it to the _same_ value when you move over to the "ITH -- Invitation Only" session. * If you are listening to the program on a normal radio, make sure to turn it off before you speak up to ask questions, to avoid any echo or feedback problems. If you have any questions about the above, send a note to Ron Frederick ... -- Ron Frederick and Steve Deering, your Internet gateway hosts -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Mon May 24 18:22:47 1993 To: rem-conf@es.net Subject: Cult Film Is a First On Internet Date: Mon, 24 May 1993 18:09:46 PDT Sender: Steve Deering From: Steve Deering Content-Length: 105 Status: RO X-Lines: 5 Check out the article with the above headline in the Business section of taday's New York Times. Steve From rem-conf-request@es.net Mon May 24 20:13:26 1993 Date: Mon, 24 May 93 22:57:27 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: rem-conf@es.net Subject: Internet video Cc: hgs@es.net Content-Length: 2623 Status: RO X-Lines: 47 The recent "barrage" of media coverage of Internet multimedia work is rather encouraging and exciting; however, let me play party pooper and introduce some words of caution. In case this needs emphasis: Currently, we have trouble getting a simple 64 kb phone call reliably from NJ to CA (I have my own recent bad experiences during the NPR show) through a 45 Mb backbone; now, compare that with 125 million calls that AT&T completes each day, where 50 lost call attempts are a reason to light up the NOC display in Bedminster, and some caution is well advised. Statements as in the article mentioned by Steve to the effect "come back in six months and things will be perfect" (although I should probably discount it as the usual selective press quote) are not very helpful and raise expectations likely to be unfulfilled. People in the systems community tend to sneer at the AI crowd promising connected speech recognition next year or language translation the year after (remember the glowing press coverage it got, too); "energy to cheap to meter" in the long run hurt the nuclear energy industry; OSI's imminent dominance year after year, and the list of examples can go on through your favorite vaporware list. There is a fine line between raising expectations that get people (vendors, researchers, network providers) to act and sounding like a sales critter for some fly-by-night software house. Unlike Marconi, the Internet has and will have plenty of competition in carrying multimedia services. Price comparisons made during the NPR broadcasts are at least currently rather misleading (a few dozen phone calls in a national infrastructure before we have to invoke network controls are VERY expensive if you want to use that as an alternative to the phone network). It seems likely that end systems will be much better in the near future (although it probably will be a PC running Windows and not some workstation running Unix where I can buy a sub-$5000 MPEG plug-in, but maybe Sun was doing some clandestine pre-release product announcing through the New York Times), but until the network can support hundreds of 64 kb/s-type calls without having to tell people to hold off on their ftp, this is strictly gee-whiz amateur-radio like stuff, not the national information infrastructure. Let's only hope that the Internet doesn't become CB radio before it joins the NII. (Remember how hot THAT was; for some humility, it might be instructive to dig out the early CB radio press reports...) I'm probably preaching to the choir here, but we may want to choose our public exposure a bit carefully. Henning From rem-conf-request@es.net Tue May 25 02:07:56 1993 Date: Tue, 25 May 93 04:51:40 edt From: John Ioannidis To: rem-conf@es.net Subject: Re: Internet video Content-Length: 571 Status: RO X-Lines: 13 Christian Huitema writes: > general case: the current voice encodings have a static bandwidth > requirement (e.g. 64kbps), and there is no way to enforce this kind of Here's a thought that just occured to me: are people considering variable-rate vocoders (such as Qualcomm's Q-CELP) and their traffic characteristics, when studying, and desiging for, voice over the internet? Does the question even make sense, or is it just similar to having a fixed-rate encoding that does silence detection and does not use the allocated bandwidth during silence periods? /ji From rem-conf-request@es.net Tue May 25 06:50:29 1993 From: Fengmin Gong Subject: Re: Internet Video To: rem-conf@es.net Date: Tue, 25 May 1993 09:39:16 -0400 (EDT) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 2728 Status: RO X-Lines: 59 > Christian Huitema wrote in a previous message: > >Henning, > >>From what we see here, there are still major items of work in front of us >before multi-media becomes a reality on the Internet. To sum up: > > * We rely on multicast IP, but multicast IP is not demonstrably working in > a large scale Internet. Current solutions dont scale well, and the work > on "multicast EGP" (or whatever you call it) is not very advanced. Maybe > we should investigate a different solution for small groups scattered > around the Internet. > Better yet, we'd need the ability to dynamically set up a multicast tree with resource reservation (forward reference to next comment). > * White-boards are still in enfancy. VJ distributed a very interesting > prototype, and others are popping here and there, but we dont have anything > like a working group or a published spec. E.g. how does one port VJ's white > board on a Mac-Intosh? On the other hand, WBs are "just data". Traffic > follows roughly the same model than Telnet or FTP. > > * Video, and in particular "interactive video", is pretty much data-like too. > There is still work to do to implement the equivalent of a "slow-start" > congestion control mechanism, but this is definitively doable. > > * Sound does not work. Well, it almost work in some cases, like on Dartnet > where resources can be reserved for "flows". But it does not work in the > general case: the current voice encodings have a static bandwidth > requirement (e.g. 64kbps), and there is no way to enforce this kind of > static reservation in the existing Internet. There are to ways out: either > develop a resource reservation mechanism, or develop variable bit rate > (variable quality) encodings, and use them in conjunction with a > "predictable network" -- e.g. one that uses some form of fair queuing. > Absolutely agree with the work need to be done. The two ways identified are more like parts of one solution. First of all, variable bit rate encodings (I prefer using adaptive applications in general) will be needed even when resource reservation mechanisms are available because there will still be congestions and the applications should be prepared to deal with them; implementation of some form of priority queueing will improve the situation without a global reservation scheme, provided that we still watch the overall load on the network as we do right now; the next logical step is to implement the reservation/admission schemes to achieve a QoS architecture like the one proposed by Dave Clark. At least that's the way we are approaching the problem. >Looks like an interesting work programme to me... > >Christian Huitema > Thanks, Fengmin Gong From frederic@parc.xerox.com Wed May 26 22:26:50 1993 From: Ron Frederick To: mbone@ISI.EDU, rem-conf@es.net Subject: New version of nv (3.2) -- now supporting color! Date: Wed, 26 May 1993 22:22:31 PDT Content-Length: 1999 Status: RO X-Lines: 38 Hello everyone... Version 3.2 of my 'nv' network video tool is now available for anonymous ftp. Binaries are present for SPARCstations, SGIs, and DECstations. Video capture support is available for the VideoPix, Indigo starter video, DEC PIP, and DEC JVideo cards. Support for the Parallax XVideo card will be available very soon. Thanks go to Andrew Cherenson at SGI and Steve McCanne at LBL for their work on making nv run on other platforms. The main new feature in version 3.2 is the addition of color. In addition to the existing 8-bit greyscale video, you can now send 24-bit YUV 4:2:2 color video. Best results are obtained if you have a 24-bit color display available, but dithering allows you to display the video on 8-bit and 16-bit systems. Version 3.2 of nv will still be able to decode nv 3.0 and 3.1 streams, and can transmit 3.0 and 3.1 compatible streams if it is told to send greyscale. However, I would recommend upgrading to this version as soon as possible. I expect most of the streams on the "MBone Video" channel to be in color, and color streams cannot be decoded at all by older versions. To retrieve nv 3.2, anonymous ftp to parcftp.xerox.com and look in the directory /pub/net-research. There, you'll find the following files: -rw-r--r-- 1 frederic 902595 May 26 21:49 nvbin-3.2-dec5k-jvideo.tar.Z -rw-r--r-- 1 frederic 755503 May 26 21:49 nvbin-3.2-dec5k-pip.tar.Z -rw-r--r-- 1 frederic 663257 May 26 21:51 nvbin-3.2-sgi.tar.Z -rw-r--r-- 1 frederic 649857 May 26 21:49 nvbin-3.2-sun4.tar.Z -rw-r--r-- 1 frederic 139713 May 26 21:49 nvsrc-3.2.tar.Z The nvsrc file contains build directories for all of the supported architectures. The nvbin files contain just the particular binary and documentation. If you have any questions or comments about nv, feel free to send me some email. The program is still under development (as my schedule permits), and I welcome feedback about it. I can be reached at "frederick@parc.xerox.com". Ron Frederick From rem-conf-request@es.net Thu May 27 16:15:32 1993 Date: Thu, 27 May 93 16:00:24 PDT From: Tom.Kessler@Eng.Sun.COM (Tom Kessler) To: rem-conf@es.net Subject: digitized version of the new york times article Content-Length: 586 Status: RO X-Lines: 14 Hello all, I located a scanner and scanned John Markoff's article about the "Wax" multicast. It's about 300Kbytes of uuencode jpeg. I think there's enough interest to post this but I thought I'd check with you all first. I'm willing to consider other formats as well (Tiff, jpeg, pbm, et. al are all easily doable by me). I also have a nicer 2 Mbyte image (where the picture is much better) in a sun raster file. I'm willing to send this to any of you who are interested or who find the jpeg version too difficult to read, or who want to see what the picture really looks like. From rem-conf-request@es.net Thu May 27 21:41:44 1993 Date: Thu, 27 May 93 21:28:07 PDT From: Tom.Kessler@Eng.Sun.COM (Tom Kessler) To: rem-conf@es.net Subject: New York Times article Content-Length: 236 Status: RO X-Lines: 12 Thanks to Larry Rowe the New York Times article on Wax can now be had via anonymous ftp from toe.cs.berkeley.edu in pub/multimedia/articles in the files nyt_wax.jpeg (Jpeg format) and nyt_wax.im1.Z (compressed sun raster file) Enjoy. From rem-conf-request@es.net Fri May 28 12:19:42 1993 Date: Fri, 28 May 1993 12:06:30 PDT Sender: Ron Frederick From: Ron Frederick To: mbone@isi.edu, rem-conf@es.net Subject: Error in nv 3.2 DEC PIP release Content-Length: 584 Status: RO X-Lines: 13 A new version of nv 3.2 is now available for the DECstation with the PIP frame grabber. The original release of 3.2 accidently contained the older grab code, which was only capable of grabbing greyscale. The sources have also been updated to fix this problem. If you picked up nv 3.2 for the DECstation, you'll want to get it again. The files are on parcftp.xerox.com in /pub/net-research: -rw-r--r-- 1 frederic parc 755555 May 28 12:03 nvbin-3.2-dec5k-pip.tar.Z -rw-r--r-- 1 frederic parc 138267 May 28 12:02 nvsrc-3.2.tar.Z -- Ron Frederick frederick@parc.xerox.com